CODE COMPLETE 第2版 下巻(2)

雨がうっとうしい。

第27章 プログラムサイズが及ぼす影響

• プロジェクトのメンバーに応じてコミュニケーションパスが乗法的に増加する。
• プロジェクトの規模が大きくなるとエラーの数は劇的に上昇する。
• プロジェクトの規模が小さいほうが生産性は高い。
• プロジェクトの規模が大きくなると、コンストラクション(開発)の割合が相対的に小さくなる
• 堅苦しいアプローチ（厳格な方法論）は適用を誤ると、利点がオーバーヘッドにより帳消しになる。

第28章 コンストラクションの管理

• コードが共有資産であることを強調する。
• PMが理解でいるコードを書く（コードを理解可能な標準を設ける）
• 構成管理
  • 手順化/体制化
• スケジュールの遅延に対する対応。
  • 増員はタスクが適切に分割されていないと即時性のある効果を挙げられない
  • プロジェクトの範囲を狭めるのが有効（機能を落とす）
• プロジェクトで何が起きているかを把握するために、各種の測定（コードの行数、空白行の数、メソッドの引数etc）を行う
• 技術経験の乏しい管理者に対しては「管理者の管理」を行う
  • こっそり洗脳する

第29章 統合

• 色々方法はあるが、直前まで統合を行わないフェーズ型（ビックバン）統合はリスクが高い
• インクリメンタル型統合のうち、適切な手法を用いる。
  • 試験や手戻りの工数を減らせる。
    • プロジェクトの開発プロセス次第…
  • トップダウン/ボトムアップ/サンドイッチ/リスク指向/機能指向/T字型
• デイリービルドとスモークテストを日次で行う
  • Jenkins使ったことないけど使ってみたいなあ

第30章 プログラミングツール

• 必要なツールは自作する
• 将来に渡っても完全な自動化にはならない

第31章 レイアウトとスタイル

• レイアウトはプログラムの論理構造を明らかにする（特にブロック）
• 優秀なプログラマでさえも、「期待するレイアウト」に沿ってないコードでは理解力が低下する
• 良いレイアウトの目標
  • コードの論理構造を正確に表現する
  • コードの論理構造の表現に一貫性がある
  • 可読性を向上させる
  • 変更に耐える（保守し易い）
  • レイアウトスタイル
    • 純粋なブロック
    • 純粋なブロックのエミュレート
    • ブロック境界の指定

      // BAD Pattern.
      if (boolean)
        {
          //statements..
        }
      // BETTER Pattern.
      if (boolean)
        {
        // statements.
        }

    * 行末インデント（原則BADパターン）
        * インデントをあわせることで可読性は高くなるかもしれないが、保守性が著しく低下する
        * 1行ステートメントは使用しない。バグの温床になる＆デバッガで実行されたかが不明（確かに！）
        * 代入文の右辺を揃えないこと // 確かによく見かけるなあ
        * データ宣言に関しては後置コメントもあり

第32章 読めばわかるコード

• プログラムソース自体がドキュメント（内部ドキュメント）
  • 変数名、メソッド名、適切な抽象化、コメント
• コメントの種類
  • コードの繰り返し（NG）
  • コードの説明（NG）
    • コードの説明が必要な場合は実装、設計自体を見直すこと
  • コードの目印（NG）
    • TODOとか。
  • コードの概要（OK）
  • コードの意図の説明（OK）
  • コード自体では表せない情報（OK）
• 効率的なコメントの作成
  • PPPの手法を使い、変更で壊れたりしないスタイルを使う
  • 方法でなく理由に充填を置く(適切な抽象化）
• データの単位はコメントで表す、よりは、変数名に含めたほうがよい
• 変数、ルーチンの許容される範囲をコメントで表す
• バージョン管理タグ

第33章 個人の資質

• どれくらい知的であるかより、自分の知性をいかに集中させるかが大事
  • 複雑さに対処し、脳の負担を減らすこと
• 粘り強さは邪魔になることが多い

第34章 ソフトウェア職人気質とは

• 複雑さの克服
• 規約を策定することで、本当に考えなければならにことに集中できる

第35章 さらに情報を得るには

• いろんな関連書籍の紹介