emahiro/b.log

日々の勉強の記録とか育児の記録とか。

『Google のソフトウェアエンジニアリング 9, 10章』

久しぶりに読書録です。

Overview

Google のソフトウェアエンジニアリング』を2022年内で通読したので、いくつか気になった章の簡易的なまとめを備忘録として記載します。
ちなみに現職の社内勉強会の一環として輪読会を開いておりその中で読み進めている内容になるので、まとめる順序は章立てに準拠はしておらず、また内容も自分自身の解釈を踏まえた主観を多分に含みますのでその点は保了承ください。

今回は特に印象的だった 9,10 章についてまとめます。

Memo

9章: コードレビュー

  1. コードは債務である と認識しろ。将来の誰かの保守運用コストがかかる。
  2. 債務である前提を元に変更(新機能開発含) が どうして必要なのかをコードを書く前に徹底的に議論 しろ。
  3. 開発者は各々がオーナーになるくらい言語特有のリーダビリティに精通してるべき(これがレビューのリードタイムを短くする)
  4. コードのレビュー時に意味の把握(複雑さの低減)or 機能性(パフォーマンス)を向上させる以外に個人の意見を理由として代案を出すべきでない。
  5. 変更は小さく、明確に説明するべし。
  6. コードレビューは 知識共有の枠組み 。
  7. コードを書く側にもプロ意識を期待する。
  8. 自分という存在と自分が生み出したコードは別物。 自分の作った差分は自分のものではなく「チームのもの」。
  9. 人間がやってる機械的なタスクは自動化せよ。

コードレビューのセクションはメンタリング的な内容が多い。

特に良かった考え方は「コードは負債であること」と「コードの作者(実装者) にもプロフェッショナルの意識を求めること」という部分。
Reviewer, Reviewee に力関係は存在しないし、自分が生み出したコードと自分という存在を分けて考えることは、絶対に身につけておきたいスタンスでもあるので、それがちゃんと記載されている、ということは一般的なベストプラクティスとして Google でも認知されているということで、自分自身のスタンスに自信を持つことができました。

10章: ドキュメンテーション

  1. ドキュメントをコードのように扱う。
  2. 組織とともにスケールし、既存のワークフローと調和するようなプロセスとツールを導入することで質の高いドキュメンテーションを継続できる。
  3. ドキュメントの価値は時間が後になってわかる。(労力がかかる割に即時的な利益を Author にもたらさない)
  4. ドキュメントは書かれることは1度だが、後読まれることは何百回、何千回とある。
  5. ドキュメントは自分のために書くものではない。対象読者のために書く。
  6. ドキュメントにおける 4W (Who = 対象読者、What = ドキュメントの内容、When = 作成時刻、Why = ドキュメントの目的)
  7. ドキュメントにもライフライムがある。
  8. 優れたドキュメントには完全性、正確性、明確性のそれぞれのトレードオフが存在する。

個人的にドキュメント(及びドキュメンテーション)の特性というのは「時間と距離を超えて伝播し、残り続けること」が価値だと考えていたので、その価値の捉え方の方向があっていたことは自身になりました。

今回紹介した2章以外にもこの『Google のソフトウェアエンジニアリング』は スケーリング持続性 をテーマとして様々なソフトウェアエンジニアリングの領域における Google の実験から得たベスト(現時点でのベターくらい?)プラクティスが詰まっている良書でした。
ページ数的にもなかなか気合が必要な一冊ですが、一読して損はない一冊かと思います。