第二章:個人技術とプロセス

要点:ユニットテスト、回帰テスト、効能分析、個人ベースのソフトウェア開発プロセス(PSP)
ユニットテストの構築基準:

は、基本的なコンポーネントを検証すべきであり、典型的にはクラス

である.

は、プログラム作成者によって作成されるべきテスト

である.

テスト後のマシンの状態は変わりません.テスト中の変化は、生成されたファイルを削除するなど、完了後に回復する必要があります.

テストは

速くしなければならない.

繰り返し可能、結果一致

独立性は、他の試験ユニットの成否性に依存しない.このため、1つのオブジェクトまたはデータ

を人為的に構築することができる.

は、すべてのコードパス

をカバーすべきである.

は、自動テストフレームワークの

に統合されるべきである.

ユニットのテストは製品と一緒にメンテナンスし、同期

を維持しなければならない.
回帰テスト:ユニットテストに基づいて、新しいバージョンがリリースされると、エンジニアはすべてのテストを再実行する必要があります.
効率分析:効率分析ツールを使用してコードをサンプリングし、注入する2つの形式の分析を行い、まずサンプリング調査を行い、性能ボトルネックコードを見つけ、それから注入分析ボトルネックコードブロックを使用して、最適化を行う.
PSP

計画-タスクにかかる時間を推定する

開発--需要分析--設計ドキュメントの生成--設計再審(同僚と再審)--コード規範(開発のために適切な規範を制定する)--具体的な設計--具体的な符号化--コード再審--テスト

記録用時

テストレポート

計算ワークロード

事後総括

プロセス改善計画

を提出

第四章二人の協力、コードの再審...

この部分では、C++コード仕様、汎用コードスタイル、汎用コードレビューについて説明します
注記:コードが何をしているのか、なぜ、どのようにしているのかを説明する必要があります(How).(Bad)How:

// loop starts i from 0 to len, in each step, it does something
for(int i=0;i

上記の注釈が悪いのは、コードの実行プロセスを説明しているが、実際の役割については何も説明していないためであり、逆に、良好な注釈は以下の通りであるべきである.

// transfer the array into a list
for(int i=0;i

復審形式:自己復審、仲間復審、チーム復審(チームvs開発者)復審の基本的な意味:1.コードがコード仕様に合致するフレームワーク2.コードが問題を解決する基本手順:1.すべてのコードが統一された警告レベル(gcc-W 1|2|3など)を通過することを保証します...
コードレビューの基本ツール:メタコメントコードに//TODO形式のコメントが表示されます.これらのコメントはコードレビューに適用され、いくつかの要求があります.

リリースフェーズでは、//TODO、//BUGは

削除されます.

復審の段階において、//REVIEWは消去されるべきか、または

と表記されるべきである.

第八章：需要分析

ソフトウェアニーズの区分:1.機能性の需要は、ソフトウェアが完成すべき機能2を説明する.製品開発プロセスの需要は、ある制約条件の下で完成する必要があります.例えば、時間、お金3.非機能性需要は、QoSとも呼ばれ、機能を完了する時間またはその他の制約4を規定する.合計需要、複数のモジュールが一緒に作業する需要計画と推定:計画に対して合理的な時間推定を行う必要がある

第九章:PM--プロジェクトマネージャ

Project Manager v.s.Program Managerの初期のソフトウェア開発において、内部コミュニケーションの代価は人員の増加に伴って急激に上昇した.PMの登場はコミュニケーションの問題を解決するためです.現在、PMは主に以下の機能を持っている:1.顧客と話し合い、ユーザー調査を組織し、ユーザーのニーズを発見する.競合製品3の理解と比較どのようにソフトウェアを利用可能にするか、役に立つ4.チームプロセスの改善簡単に言えば、PMは開発とテスト以外のすべてのことをします.

第十章典型的なユーザーとシーン

第一の分析方法:典型的なユーザーを分析し、典型的なユーザーが関わる典型的なシーンを分析する第二の分析方法:Use Case、すなわちユーザー用例第三の方法:規格説明書、ソフトウェア機能説明書とソフトウェア技術説明書を含む機能説明書を書くために、まずいくつかの概念を定義しなければならない.

第十一章ソフトウェア設計と実現