アジャイルプラクティス

book

遅ばせながら読みました。巷の噂どおり訳本とは思えない読みやすさ。基本的には新しいことは言ってないので、「そうそう」と大きくうなずきながら読んでいて、イメージとしてはチームのメンバーに説明したりする時に、分かりやすくて適切な言葉がちりばめられているので、それをMemoしながら。という感じ。
苦労してきた過去があるので、ちょっと胸が詰まったりする箇所があって、嬉しい1冊。
各章、悪魔のささやき、天使の助言、こんな気分、バランスが肝心の4つの構成から成っていて、リズムがあって頭に入りやすい。特にバランスが肝心部分は、そうは言っても現実解は。と突っ込まれそうな部分をうまく解説していて、これもチームがなにかにぶつかった時に使えそうだな。とにやりとしながら読めた。巻末にある天使の助言集はとてもいい。

■読みながらのMemo。一覧を見ると、自分が弱い部分と過去に巧く乗り切れなかったところが多い気がする

    • 道を間違えたならどれだけ進んでいたとしても引き返せ
    • 選んだ道が正しくても、座り込んでいたら轢かれる
      • 動き続けること
      • 時が来たら習慣を捨てる必要がある
    • 成功が記憶に残るようなお祝いをしよう
    • 避けて通れない敵とは"変化"だ
    • 設計は指針であって指図ではない
    • TestFirst＝作る前に使う
    • 自分でもよく分かっていないことを厳密にしても意味がない
    • Planに価値はない。Planningが肝心
    • 初日にデプロイの仕組みを用意する(特に緊急リリース用）
    • PIEの法則（Program Intently and Expressively)
    • 「あとで書く」はない
    • コードで伝える。コメントはコードの意図や制約を示すだけで、機能を説明するものではない
    • ブタとニワトリ
    • メンターになるとは自分の知識を分かちあうこと
    • Version管理システムの向こうでチームが待ち構えていると思える
    • Agile開発の主な目的は、開発者を助けること。それがユーザと組織のためとなる


■参照資料としてあげられていて読み直そうMemo


■今すぐ展開しようと思ったもの

    • 各メソッドのコメント
      • 目的：なぜこのメソッドが存在するのか
      • 必要条件（事前条件）：メソッドの呼び出しに必要とされる引数はなにか。呼び出し時にObjectはどういう状態であるべきか
      • 結果（事後条件）：メソッドが正常終了した場合に、Objectがどういう状態か。戻り値には何を返すか
      • 例外：異常が起こった場合にどんな例外が送出されるか
    • 手続き型のコードでは、情報を取得して自分で処理をする。OO指向のコードではオブジェクトに処理を命ずる
    • ソリューションログ。問題/解決のログをとる。またチームが重大な決定を下した時にはその理由を記録
    • コードレビュー
      • そのコードを読んで理解できるか？
      • 明らかなエラーはないか？
      • アプリケーションの他の部分に悪影響を与えてないか？
      • コードに重複はないか？
      • リファクタできる余地はないか？

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣