2.0 第2部の紹介: ソフトウェアプログラミング
第2部は、多くの人が読み、変更し、長い寿命にわたって信頼できるソフトウェアを書く、日々の技芸についてです。第1部では、チームがどう組織し、どう決めるかの基礎を築きました。この部では、コードそのものに目を向けます。従う規約、設計とインターフェースの形づくり方、作業のテストとレビューの仕方、ソースの履歴の管理の仕方、そして物事の書き留め方。これらは、デリバリーを速めるコードベースと、あらゆる変更に抗うコードベースを分ける実践です。
大規模なチームでは、技芸は個人の好みの問題ではありません。それは調整の方法です。何百、何千というエンジニア、契約者、後任者が同じシステムに触れるとき、共有された規約と明確な契約が、絶え間ない衝突なしに全員が並行して作業できるようにします。コードは書かれるよりはるかに多く読まれ、その読むことの多くは、会うことのない人々によって、何年も後に行われることを忘れないでください。
企業や政府の設定では、賭け金はさらに上がります。システムは日常的に作者より十年以上長生きします。規制と監査は、統制の文書化された証拠を求めます。知識は、人員の入れ替わりと契約の境界を越えて伝わらなければなりません。そこで、ここの章は品質を、英雄的行為としてではなく、チーム全体の働き方の、設計され、大部分が自動化された特性として扱います。
この部の章
2.1 コーディング標準とスタイル: 命名、書式、イディオムのための、共有され自動的に徹底される規約で、多くの作者が一人の注意深い作者が書いたかのように書けるようにし、レビュアーがスタイルではなく設計に注意を向けられるようにします。
2.2 ソフトウェア設計の原則: SOLID(五つのオブジェクト指向設計原則)、DRY(繰り返すな)、結合度と凝集度、ドメイン駆動設計(ビジネス領域の言葉でソフトウェアをモデル化する)のようなヒューリスティクスを、従うべき法則ではなく、適用範囲と既知の失敗モードを持つ道具として扱います。
2.3 APIとインターフェースの設計: システムとチームが出会う契約を設計し、独立したチームが、利用者を壊したり足並みを揃えたデプロイを強いたりせずに内部を変更できるようにします。
2.4 テスト戦略: 何を、どのレベルで、どの確度でテストするかについての意図的な選択で、大きな組織が頻繁かつ安全にデプロイできるようにする、速くて信頼できる安全網を築きます。
2.5 コードレビューとコラボレーション: マージの前に変更を検査し、欠陥を捉え、知識を広め、標準を徹底し、コンプライアンスの統制を満たしながら、レビューを形式的にならず速く建設的に保ちます。
2.6 バージョン管理とソース管理: あらゆる変更の記録のシステムと、メインラインをリリース可能に、履歴を読める状態に、監査証跡を無傷に保つ、ブランチ、リポジトリ、コミットの規律。
2.7 ドキュメント: はじめにガイドからランブック(段階的な運用手順)、決定ログまでの、書かれた知識で、特定の人物へ依存するリスクを防ぎ、オンボーディングを加速し、何年にもわたり契約の境界を越えて理解を伝えます。
2.8 ソフトウェア要求: ソフトウェアが何をすべきか、どれだけうまくすべきかを、規制された仕事や政府の仕事が求めるトレーサビリティとともに、引き出し、規定し、検証し、管理します。
2.9 ソフトウェア構築: 動くソフトウェアを作る技芸。複雑さを最小限にし、検証と変更のために構築し、防御的プログラミングを行い、規律ある再利用をします。
2.10 ソフトウェア構成管理: あらゆる構成アイテム(バージョンを追跡し管理しなければならない成果物)と変更を識別し、管理し、監査して、リリースが再現可能で、監査証跡が無傷であるようにします。
2.11 ソフトウェア品質: テストより広い、管理される特性としての品質。品質モデル、保証と管理、測定、欠陥管理、品質のコスト。
2.12 ソフトウェアのモデルと方法: いつ、どうモデル化するか。構造モデルと振る舞いモデル、形式手法(数学に基づく仕様と検証)、プロトタイピング、アジャイル手法、そしてモデル化が無駄になるのはいつか。
2.13 計算、数学、エンジニアリングの基礎: 実践の下にある不変の基礎。アルゴリズムとデータ構造、論理と確率、経験的なエンジニアリング手法。
2.14 プロジェクトとリポジトリの構造: ソリューションとそのリポジトリを整理するための一貫した規約。標準的なフォルダ、READMEの入口、共有の設定を含み、どのエンジニアもどのコードベースでも道に迷わないようにします。
2.15 デバッグとトラブルシューティング: 当てずっぽうや散弾銃的な変更ではなく、再現、二分探索による切り分け、仮説の形成と検証、各修正の回帰テストとしての記録という、規律ある教えられる実践としての、欠陥の発見と修正。
2.16 パフォーマンスエンジニアリング: 性能の予算を設定し、最適化の前に測定とプロファイリングを行い、アルゴリズムのコストとテールレイテンシを理解し、退行を防ぐことによって、コードとコンポーネントのレベルで、ソフトウェアを意図して十分に速くすること。
2.17 並行性と並列性: 不変性とメッセージパッシングを既定とし、競合状態、デッドロック、メモリの可視性を理解し、適切な同期と高水準のモデルを選び、非決定的な振る舞いを意図してテストすることで、正しい並行コードを書くこと。
2.18 依存関係とサプライチェーンの管理: バージョンの規律とロックファイル、安定した更新の周期、最小限で審査された依存関係の足跡、そして信頼できるサプライチェーンのための来歴とソフトウェア部品表を通じて、現代のシステムの大半を構成するサードパーティのコードを管理すること。
2.19 リファクタリングと技術的負債: 信頼できるテストスイートの背後で、動いているコードの内部設計を改善し、コードの臭いを認識して小さな名前付きのリファクタリングを適用し、より大きな変更にはストラングラーフィグを使い、技術的負債を道徳的欠陥ではなく、可視で資金のあるポートフォリオとして管理すること。
2.20 エラー処理とレジリエンスのパターン: 明確なエラー契約、フェイルファストとフェイルセーフの選択、バックオフと冪等性を伴うリトライ、サーキットブレーカーと縮退運転、そしてエラーを黙って握りつぶさないことを通じて、コードがどう失敗し回復するかを意図して決めること。
2.21 型システムと静的解析: 不正な状態を表現不可能にする静的型付けと段階的型付け、そしてエディタとパイプラインに組み込まれたリンター、型チェッカー、アナライザーによって、コードが動く前に欠陥の分類全体を捉えること。
これらの章の相互関係
第2部を貫く糸は、規模における変更容易性です。ここにあるすべての実践は、多くの人が、共有された長寿命のシステムを自信を持って変更できるようにするために存在します。コーディング標準(2.1)と設計原則(2.2)は、理解し変更できるようにコードを形づくります。インターフェース設計(2.3)は、チームが独立して内部を変更できる境界を引きます。テスト(2.4)は、変更を安全にする安全網を提供します。コードレビュー(2.5)は、個人の仕事が集団のオーナーシップと出会う場であり、標準が実際に徹底される場です。バージョン管理(2.6)は、レビュー、統合、監査のすべてが拠って立つ基盤です。そしてドキュメント(2.7)は、そのすべての背後にある意図を、後から来る人々のために保存します。
これらの章は、本書の残りにも流れ込みます。ここのインターフェースと設計原則は、第3部のシステム、特にアーキテクチャの基礎(3.1章)の構成要素になります。テスト戦略(2.4)とバージョン管理(2.6)は、8.1章の自動化されたデリバリーパイプラインの素材です。ドキュメントの実践(2.7)は、9.2章のような運用のランブックとオブザーバビリティに直接つながります。そして部全体は、第1部で築かれた価値観と意思決定の基礎の上に立ち、共有された原則を、具体的な日々の技芸に変えます。