読書メモ 『Googleのソフトウェアエンジニアリング』

英語版はオンライン無料で存在してる

あります。
https://abseil.io/resources/swe-book

なので、書籍版は一旦読んだら破棄したり誰かにあげてもいいかもですね。
本は無限に増えるので（一方で、初読の体験は電子書籍ではない、現物の書籍に勝るものはないと思います）、参照用にオンライン版あるのは助かりますね。

まとめ

グーグルという世界一とも言える大規模ソフトウェアエンジニア集団でのチーム運用、テスト、コードレビュー、CICDなど、についてのプラクティスを知れる。もともと凄腕エンジニア集める、というだけだったところから、スケールしていく上で、どのように標準化していったかがよくわかる。
分厚い本で、ルールのような部分が網羅的に公開されているページもある。

使い方としては、自分の組織で、ここの運用スケールしていないな、とか、このレビューの在り方が納得いかないけれど、どうしたら、いい？と思った時に、この高度に標準化、スケールしているGoogleのやり方が一つの参照項として役立つと思う。

評価についての記述が欲しかった。

持続可能なプログラミング、という通底するテーマがよかった。

以下いくつかメモ

よくスケールするポリシー

p.17

我々が気に入っているポリシーに、インフラストラクチャーの強い味方で、インフラストラクチャーの変更を安全に行う能力を保証してくれるものがある。「製品が、インフラストラクチャーの変更の結果として障害や他の問題に陥った場合、問題が継続的インテグレーションシステムでのテストで表面化していなかったならば、インフラストラクチャーの変更に落ち度はない」と言うポリシーだ。より砕けた言い方するなら、「そんなに好きならそいつにCIテストつけときゃよかったのに」となり、これは我々が「Beyonceルール」と呼ぶものである
注.ビヨンセの人気曲『Single ladies』から来ている。「そんなに好きならそいつに指輪はめときゃよかったのに」と言うサビがある

エンジニアリング生産性の計測

p.160-161

ゴールとシグナル、メトリクス、を決める。
例
コードの品質
ゴール：エンジニアはリーダビリティプロセスの結果としてより高品質なコードを書いている。
シグナル：リーダビリティを認められたエンジニアが、リーダビリティを認められていないエンジニアより認められたエンジニアのコードの方がより高品質であると判定している。
メトリクス：四半期ごとの調査。自分自身のコードの品質に満足していると報告するエンジニアの比率。
例２
速度
ゴール：リーダビリティプロセスの結果としてエンジニアはより生産的になっっている。
シグナル：リーダビリティを認められたエンジニアが書いたChange Listは、リーダビリティを認められていないエンジニアが書いたChange Listよりレビューが速い。
メトリクス：リーダビリティがある作者とない作者からの、Change Listのレビュー時間の中央値

コードレビュー

小さな変更を書け
コードレビューのプロセスを機敏なものに保つ上で、最も重要なプラクティスはおそらく、変更を小さく留めておくことだ。理想的にはコードレビューは、レビュアーと作者双方のために、噛み砕いて理解することが容易で、かつただ一つの問題に集中したものであるべきた。グーグルのコードレビュープロセスは完全なプロジェクトの形をとるものが複数入っている大規模な変更は行わないよう勧告しており、レビュアーはそのような変更を、一回のレビューには大きすぎるとして正当に拒絶できる。

小さな変更とは通常、約200行までのコードに限定されるべきだ。それと同じくらい重要なてんとして、変更が小さければ、グーグルでの変更の大半は、約一日以内にレビューされることが期待されている。

CI is Alerting

CI Is Alerting
Titus Winters

As with responsibly running production systems, sustainably maintaining software systems also requires continual automated monitoring. Just as we use a monitoring and alerting system to understand how production systems respond to change, CI reveals how our software is responding to changes in its environment. Whereas production monitoring relies on passive alerts and active probers of running systems, CI uses unit and integration tests to detect changes to the software before it is deployed. Drawing comparisons between these two domains lets us apply knowledge from one to the other.

ここだけ英語の方を引用。
CIはアラートとして作ろうよというような意味。
監視のためにシステムを入れるみたいに、CIを準備して、よくないことを気付けるようにする。

これは自分的には新しい支店だった。

まだまだある

満遍なく要約するよりもピンポイントで面白かったポイントが抜き出てる方がいい要約な気がするので、
こんな感じでまとめました。

是非一読してみてください。