arveltのソフトウェア技術メモ

Arvelt's software technology memo

Codecomplete下 自分用まとめ

3年前に買ったまま理解できずに放置してたcodecompleteを読み直したので自分用まとめ。これらの項目について説明できるか?


「第5部 コードの改良」
第20章
○ソフトウェアの品質
・プロジェクトごとにソフトウェアの品質目標を設定する。
・様々な方法、開発の段階ごとに行うことでエラー検出率は上がる

第21章
○コラボレーティブコンストラクション
・誰かに話すだけで自分で問題の原因に気づく場合がある。
ペアプログラミングは全てに対してではなく、最適な箇所に使う。
・インスペクション、ウォークスルー(非公式なレビュー)、ソースリーディングを適切に行う。

第22章
デベロッパーテスト
単体テストコンポーネントテスト、統合テスト、システムテスト、回帰テスト
ホワイトボックステストブラックボックステスト
・全てのステートメントを一度は実行するテスト
・データフローテスト
・同値分析テスト
・境界分析テスト
・エラーの分類
2割のルーチンが8割のエラー
多くの原因はコンストラクション以外に由来
入力ミスは意外と多い
設計への誤解
テストケース自体のエラー
・自動テスト
テストファースト開発

第23章
デバッグ
・欠陥の検出のヒント
手に入る全てのデータを使って仮説を立てる
何種類かの方法でエラーを再現する
疑わしいコードの範囲を絞り込んでいく
最近変更されたコードをチェックする
誰かと問題について話してみる
コンパイラのメッセージの行番号を信用しすぎないこと
コンパイラのメッセージを信用しすぎないこと
コメントや引用符の閉じ忘れを確認する
・欠陥の修正のヒント
問題を正しく理解する
問題だけではなくプログラムを理解する
元のソースコードを保存する
症状ではなく問題を修正する
理由が正当な場合のみ修正する
変更は一度に1つずつする
修正を確認するためのテストをする
回帰テストをする
同様のエラーがないかを探す

第24章
リファクタリング
・ソフトウェアの目に見える振る舞いを変えずに、内部構造を理解しやすく安価に修正しやすくできるようにするための変更「Refactoring」(Fowler 1999)
リファクタリングする理由
コードが重複している
ルーチンが長すぎる
インターフェースの抽象化に一貫性がない
引数が多すぎる
変更が発生したら複数のクラスを修正しなければならないとき
クラスのルーチンよりも他クラスのルーチンを多く使う
ルーチン名が不適切データメンバがパブリック
サブクラスがスーパークラスの一部のデータしか使用しない
複雑なコードを説明するためにコメントが使われている
グローバル変数が使用されている
リファクタリングの詳細
データレベル
ステートメントレベル
ルーチンレベル
クラス実装
クラスインターフェース
システムレベル

第25章
○コードチューニング戦略
・測定する。経験や想像は当てにならない
・要求、構造、設計、実装。規模の大きい場所から考慮していく。
・非効率の一般的な例
入出力処理
ページング
システムコール
インタープリタ言語
プログラムのエラー

第26章
○コードチューニングテクニック
・ロジック
答えがわかったところで評価をやめる
頻度順に評価する
複雑な評価をテーブルに置き換える
遅延評価を使用する
・ループ
ジャミング
展開
処理の最小化
入れ子における順序
強度の変換
・データ変換
浮動小数点を整数へ
配列の次元数の削減
配列参照の削減
補助的なインデックスの使用
キャッシュの使用
・式
代数的に等価な式を使用して演算を削減
演算の強度を削減
システムルーチンを警戒
計算済み結果の使用
ホットスポットを低水準言語に書き換える


「第6部 システムの考察」
第27章
○プログラムサイズが及ぼす影響
・人数が増えるとコニュニケーションコストは指数関数的に増えてしまう。文書等による情報共有を行う。
・プロジェクトの規模が多くなるに連れて、コンストラクション以外のアクティビティにおけるコストが増大する。
・プロジェクトの規模に合わせた方法論を用いる必要がある、

第28章
○コンストラクションの管理
・コードをプロジェクトの共有資産と考え、よいコーディングを奨励する。
・構成管理
文書、ドキュメント、ソースコード、バックアップ、プロジェクトに関わる成果物を管理すること
変更手順を管理する
バージョン管理ツールの使用
・コンストラクションスケジュールの見積り
目標を立てる
計画を立てるための時間を設ける
要求を全て洗いだす
下位レベルの詳細を見積もる
何種類かの方法で行った見積りを比較する
定期的に見直す
・スケジュールの遅れを取り戻すために
チームを増強する(タスクが細分化されていることが前提)
プロジェクトのスコープを狭める
・プロジェクトに関する様々なことを測定する、想像で判断しない
プログラマが人間であることを認識する
生産性には個人差がある
チームによっても生産性は異なる
物理的な環境が生産性に影響する

第29章
○統合
・フェーズ型、段階的にモジュールを統合していく
・インクリメンタル型、1つずつモジュールを統合していく
トップダウン型
ボトムアップ
サンドイッチ型
リスク指向型
機能統合型
T字統合型
・デイリービルドとスモークテスト
毎日ビルドし、失敗していないかを検査する
毎日スモークテストをする
ビルドとテストを自動化する
切迫した状況でも怠らないようにする

第30章
○プログラミングツール
ソースコードの編集に役立つツール
IDE
一括検索、一括置換
diff
マージ
整形
インターフェース自動化
テンプレート生成
・品質をチェックするツール
構文チェック
測定
リファクタリングツール
・バージョン管理
・ビルドツール
デバッグツール
・テストツール


「第7部 ソフトウェア職人気質とは」
第31章
○レイアウトとスタイル
・論理的構造とレイアウトを一致させるようにする
・制御構造
beginとendを2重にインデントしない
改行でグルーピングする
複雑な式は条件をそれぞれ別の行にする
case文に行末インデントを使用しない
・ステートメント
スペースをうまく使い明確にする
関連する要素を1つにまとめる
継続行の終わりを明確にする
代入文の右辺を揃えない
1行に1つのステートメントを書く
・データ
1行に1つのデータ宣言する
変数は最初に使用する場所で宣言する
・コメント
コメントは該当するコードに揃える
・ルーチン
ルーチンの引数にインデントを使用する

第32章
○読めばわかるコード
・コメントの付け方
そのコードの意図を書く
方法ではなく理由を書く
変更しやすい書き方にする
行末コメントを通常使用しない。データ宣言、ブロックの終端などで使う
技巧的でわかりづらいコードはコメントをつけるのではなく書き直す
データの意味を行末コメントで記す
制御構造の前にコメントをつける。終端につける
引数の宣言部に行末コメントをつける
ファイルの冒頭に、目的と内容をつける
ファイルの冒頭に、製作者の名前、連絡先等をつける

第33章
○個人の資質
・プログラミング能力は個人の資質と関係がある
・それは謙虚さ、好奇心、知的な誠実さ、創造性、規律、啓発的な怠惰である
・もっとも重要なのは才能ではなく意欲である
・よい資質は正しい習慣を持つかどうかにかかっている

第34章
○ソフトウェア職人気質とは
・プログラミングとは複雑さに対処することである
・プロセスは製品の品質に影響する
・チームプログラミングではチームでのコミュニケーションが品質に影響する
・解決策ではなく問題の観点にたちプログラミングすると複雑さを克服するのに役に立つ
・独断的な手法では高品質なソフトウェアは作れない。作業に適した道具を選択する能力を身につける


Code Complete第2版〈上〉―完全なプログラミングを目指して

Code Complete第2版〈上〉―完全なプログラミングを目指して