CODE COMPLETE を読み始めた。
Code Complete 第2版 上 完全なプログラミングを目指して
- 作者: スティーブマコネル
- 出版社/メーカー: 日経BP社
- 発売日: 2014/04/02
- メディア: Kindle版
- この商品を含むブログ (12件) を見る
Code Complete 第2版 下 完全なプログラミングを目指して
- 作者: スティーブマコネル
- 出版社/メーカー: 日経BP社
- 発売日: 2014/04/02
- メディア: Kindle版
- この商品を含むブログ (9件) を見る
ちょうど第１部を読み終えたのでメモをブログに載せておこうと思う。
読み始める前は「綺麗なコードを書くための細かいテクニックがたくさん載っている本」だと想像していたのだが、思ったよりも体系的に書かれていた。 もちろん、最も重点を置いているのは「コードの構築（コンストラクション）」の部分なのは間違いないのだが。
はじめに
- 論文などで紹介されているバグを防ぐテクニックを、一般ソフトウェア業界に提供するための本である
- ソフトウェアコンストラクションとは：詳細設計からテストまで。コーディングとデバッグを含む
- 従来の時間をかけて伝承されるような知識を効果的に提供する
- コンストラクションには全体の5割以上のエラーが含まれている。ここにリソースを投入する価値は高い
- 要求とか設計は無視されることがある一方、コードは必ず実行される
第１部：基礎を固める
第１章：ソフトウェアコンストラクション
- コンストラクションは何かを作る作業のこと
- ソフトウェアコンストラクションの中心はコーディングとデバッグ。ただし、詳細設計やテストも多少含まれる
- なぜソフトウェアコンストラクションか？
第２章：メタファ
- 科学はメタファを用いて発展してきた
- メタファによって、プログラミングの問題を理解するための方法が学べる
- プログラム作成を「手紙を書く」というメタファにするのはそこまで正しくない。一人ですべて書き上げることはないし、プログラムに高いオリジナリティは必要ない
- 「農場」というメタファもあるが、農場のメタファは適切でない。農場では人間によってコントロールできない「天候」に左右される
- アクリーション（「堆積」、「添加」、真珠の「養殖」の意）が適切。インクリメンタル型を示唆している
- コンストラクション（構築）も最適。このメタファから様々なメタファに広げられる
- 「十分な計画」と「なんでもすべて計画する」のは違う。後での変更も見込んでおくのが「十分な計画」
- ソフトウェアテクニックは「道具箱」というメタファが適切。職人が適切な道具を見つけられる様子を暗示する
- メタファは曖昧である。アルゴリズムのように決定的ではない
第３章：上流工程の必要性
- コンストラクションの規模によって「準備」の規模は変わる
- コンストラクションの準備は重要
- コンストラクションの前後、その中でも、すべてのフェーズで品質をあげることは可能
- 上流工程にも必ず意味がある
- 実際、「上流工程に意味はない」というデータはあまり見当たらない
- 上流工程によってリスクを低減する
- 準備不足は開発者のスキル不足によって多く起こる。スキルがなければ人間の数を増やしても意味がない
- 一刻も早くコーディングに取り組みたがる開発者が多いので注意
- Why isn’t sam coding anything 問題
- 上司にコーディング以外も需要だと思わせる必要がある
- プロセスの速い段階で欠陥を取り除くと手戻りが10〜100倍少ないという研究結果がある
- 逐次型にしろ反復型にしろ、「準備のあり・なし」が大事
- 準備：「プロダクトビジョン」「ビジョンステートメント」「ミッションステートメント」などと呼ばれている
- 課題を間違えると、時間がなくなる上に、解決するべき本当の課題も解決されない
- 要求は変化する。関わりが長くなると分かってくるから
- 要求の変化を認めないと、顧客の意見を無視していることになる
- 要求の評価が低い場合は、作業を中止して正しく策定する
- 要求変更管理手順を決めておこう。回数は少なくなるが、顧客からの窓口は持っていることになる
- 常にビジネス上の価値を再考しよう
- アーキテクチャを決定する。アーキテクチャはソリューションになる
- アーキテクチャはコンストラクションの手引き書となる
- 設計の根拠が、設計自体と同じくらい重要。そのためには破棄した代替案の痕跡などを残しておくとよい
- アーキテクチャには様々な要素がある。モジュール校正・リソース・パフォーマンス・エラー処理など、、、
- 一般的なプロジェクトでは工数の 10~20% を、スケジュールの 20~30% を計画にあてる
- 詳細設計と計画は異なる
- 要求やアーキテクチャが決まらないと見積もできない
- プロジェクトのサイクルを通して品質は常に配慮する
第４章：コンストラクションの重要な決断
- その言語に慣れているかどうかはプログラマの生産性に関わる
- その言語の経験があるかどうかも生産性に関わる
- 高級言語の方が生産性が高い
- 高品質なソフトウェアではアーキテクチャの概念的な整合性と、実装の表現が一致している
- 変数名、クラス名、ルーチン名、フォーマット規約、コメント規約など
- プログラミング規約によってばらつくべきではない点は統一させる。
- 一方、ばらついて当然の箇所もある
- テクノロジーには始まりの波と終わりの波があるのでどちらのテクノロジーかを意識する
- 言語の「中へ」のプログラミング。表現したいものを言語を通して実装する
- 言語にその機能がない場合、規約やライブラリでカバーできる。ベースの概念は一緒である事が多い
- 言語の「中で」プログラミングしてはいけない
- 発想やアイディアを言語に縛られてはいけない