kawasima

アーキテクチャ設計のドキュメンテーション

コンテキスト

アジャイルプロジェクトのアーキテクチャは、別々に記述され定義されなければなりません。すべての意思決定が一度にされるわけでもなく、プロジェクト開始時にすべての意思決定がされてるわけでもありません。

アジャイル手法では、ドキュメンテーションに反対はしませんが、価値のないドキュメンテーションはいけません。チーム自身の助けになるようなドキュメントは価値がありますが、ちゃんと最新化し続けなければなりません。膨大なドキュメントでは、最新化されなくなることでしょう。小さくまとまりのあるドキュメントは少なくとも更新される可能性はありますよね。

また膨大なドキュメントはだれも読みません。たいていの開発者はソースコードサイズの合計よりも(byte的な意味で)大きな仕様書が書かれたプロジェクトを少なくとも1回は経験したことがあるでしょう。開くのにも、読むのにも、更新するのにも、そんなドキュメントは大きすぎます。一口大のピースに分解すれば、すべての関係者にとって消化するのは簡単になりますよね。

プロジェクトが動いている間、追跡するのが難しいことの1つに、ある意思決定の裏に隠された「思い」があります。プロジェクトに新しく参画した人は、それまでに決定されたことに困惑したり、戸惑ったり、喜んだり、怒ったりすることでしょう。理念や因果関係を理解しておかないと、その人は次の2つの選択をすることになります。

scova0731

定番、および比較的最近の学習リソースを集めてみました (2015/2)。

リファレンス

• Scala (by ひしだまさん) : 網羅的。特にコレクションのメソッド一覧など。
• Scala School (英)(Basics意訳 by 瀬良さん): Twitter社による入門記事
• Effective Scala (日本語版) : Twitter 社によるベストプラクティス集
• 公式Scala Documentation - ガイドと概要 : 2.8時代のですが、コレクション・Futureなどについて詳解

記事等

j5ik2o

ペアプロの心得

休憩をとる

1.定期的に休憩をとっていますか？ ペアプログラミングは、精神的な体力を消耗します。定期的に休憩をとってリフレッシュすることがとても大切です。

謙虚になる

2.「色々な実装方針がある」という認識がありますか？

gabu

def gabu(id: String, bid: String) = Action {
  Project.findOneByID(id) match {
    case Some(project: Project) => Build.findOneByID(new ObjectId(bid)) match {
      case Some(build: Build) =>
        // etc...
        Ok(views.html.gabu(build)
      case None => NotFound
    }
    case None => NotFound
  }

rirakkumya

package controllers

import play.api._
import play.api.mvc._
import play.api.cache._
import play.api.Play.current

object Application extends Controller {
  import EA._
  def index(id:String) = EitherAction {req =>

rirakkumya

def index(id:String) = Action {
  getFirstData(id)
}
private def getFirstData(id:String) = {
  Cache.get(id) match {
    case Some(id2) => getSecondData(id2)
    case None => NotFound
  }
}
private def getSecondData(id2:String) = {