✓【読書】Googleのソフトウェアエンジニアリング
syossan276.1
リーダーによるトレードオフの特定とそれを踏まえた決定・反復。
ここ凄い共感したし、これが全てくらいに思ってる。
syossan27仕様の範囲 × 実装時間 × コスト = 鉄の三角形
syossan27トレードオフを精緻に見極め、スライダーを定量的に判断し動かすことで決定に繋げる
syossan27自律組織を作る要素
・問題の変化に対応出来る境界の緩いチーム管理
・部分問題の移譲によるSPOFの回避
・観察、傾聴を経た反復的なチームのベクトル調整
=〉いつでも去れるようになったら成功
syossan27インポスター症候群：自己肯定が上手く出来ず、自己を過小評価してしまう心理状態
syossan27自己をスケールさせるための要点
・重要タスクを見極める（緊急≠重要）
・重要タスク以外は移譲
・他人でも出来るボールは意図的に落とす
・ICの時より厳格に"エネルギー"を管理する
=>問題に対してreactiveにならずにproactiveになる
syossan27決定のためには常にデータが必要
-> ただし、データがあっても決定に100%用いられるとは限らず、データが正確でなくとも決定に寄与する場合もある
-> 「計測の成功とは決定を行うのに必要なデータを"利害関係者が使った"時」
syossan27街灯効果: 見える場所のみを探しても正しい場所を探しているとは限らないという故事。
引用した意図的にはマクナマラの誤謬の方が近そう？
syossan27メトリクスは常にゴール・シグナル・メトリクスに紐付けて作成
-> GSMフレームワーク
syossan27ゴール策定の揺らぎを防ぐ生産性に関する５つの中心的構成要素
・コード品質
・エンジニアの注意
・知的複雑性
・テンポと速度
・満足
-> QUANYS
syossan27定量的メトリクスは文脈とナラティブを提供しないため、シグナルにおけるメトリクスには定性的調査を含めることも考慮する
syossan27組織によってスタイルガイドなどのルールは変化してくる。組織が持つ価値観に沿ったルールを作らないと意味がない。
-> Googleがやっているから真似しよう、ではいけない
syossan27スタイルガイドとルールの章を読んでいるとGoogleでGoが誕生したのも頷ける気がしてきた
syossan27空白文字が何文字でも構わない。一つの一貫したルールを決めることで余計な議論を避け前に進むことができる。
と言いつつもPythonでは社外のコミュニティ基準に従って空白文字数を変えた経緯もあり、十分な論拠があれば新たな一貫性を生み出すこともある。
syossan27コードレビューについて、Googleはオーナーシップをルールとして敷いているがシングルリポジトリでコードベースを管理しているGoogleならではだと思うし、日本でこの恩恵が預かれる規模感の会社はめちゃくちゃ限られそう🤔
syossan27コードレビューの一番の効能は、PR作成者のバイアスが全くかかっていない状態でのフィードバックを提供すること。
初めてコードを読む人にとって意味が把握しやすいコードになっているかの検証がやりやすいため、レビューをする際にはその観点を念頭に置くこと。
syossan27PRによる変更は200行ほどの小さなものが望ましいとあるが何故200行なんだろうか？（本文中に理由記載無し）
ネット上も探したが特に見つからず。
syossan27良質なドキュメンテーション
・対象読者を特定している
・明確な文章となるよう短く保たれている
・単一の物事についてのみ書かれている
syossan2710章のドキュメンテーションについてを読み終わった。
やっぱりドキュメントは重要だし、その鮮度と質を保つということはGoogleであっても苦心してるんだなーという感じ。
syossan2711章 テスト
Googleではテストを速度と決定性(ref:信頼不能テスト)によって以下の3つに分けられる。
小テスト：単一プロセス内で実行される。速度と決定性: ○。
中テスト：単一マシン内で実行される。速度と決定性: △。
大テスト：複数マシン上など好きな場所で実行される。速度と決定性: ✕
syossan27信頼不能性が高まることはテストへの不信感を生み、テストを書きメンテナンスする文化の破綻の序章となる。
-> 信頼不能性が1%を超えるとテストの価値が揺らぎ始める(Googleでは0.15%辺り)
syossan27この本、独自ルールや法則が出てくるのでここまでに出てきたのを軽くまとめる。
Hyrumの法則：APIに対してどういう契約仕様で作られたかをユーザーは考慮せず、ただ振る舞いに依存する
Beyonceルール：「そんなに好きなら(≒ 破綻して欲しくないなら)そいつにテスト付けときゃよかったのに」
syossan27テストは複雑になり始めたら危険なサイン。常にパッと見で分かる単純明快さがあるかを確認する。
DRYなどコードを書く際に気にする原則は横に置き、DAMPを目指す。
syossan2713章読み終わったが、いまいちハラオチしなかった。（当たり前じゃん的な理解が多かったからか？）
折を見てハラオチのために別で軽くまとめたりするかも。
syossan2714章突入してから全然メモってなかった。
ちょいと知らない単語の拾い上げをば。
劣線形: 字の通り線形より劣った線形。線形通りにスケールしていないことを示す。
バグバッシュ: システムを全員でポチポチ触る会。
syossan27A/Aテストによる非決定性の挙動、ノイズ、信頼不能生などを特定する、というのは言われてみれば確かにという感じ
syossan27やっとこさテストゾーンから抜け出せた・・・
大規模テストの章についてはユニットテストに比べてトレードオフの係数が多くなって、そこの適切性を見極めようみたいな話がほとんどだった。
syossan2715章 廃止 に突入。
9章に紐付く話だが、コードは債務であり資産ではないという前提から話が進んでいる。
syossan27Hyrumの法則に当てはめて考えてみると実装者が想定しない使い方をユーザーがしている場合には廃止は非常に難易度が高まる、というのはなるほどと思った。
特に利用している振る舞いがバグであったならより難しい。
syossan2715.3.2 強制的廃止の文脈で出てきた赤の女王仮説
syossan27廃止に対する警告はただの"希望的戦略"であり、ユーザーからするとアラート疲労を引き起こす可能性が高まる。
-> 重要な２つの警告属性を考える。
・行動可能性：警告に基づいて依存脱却のアクションを行える
・関連性：廃止予定のアクションをした際に警告
syossan2716章のバージョン管理、あんまりピンと来なかったので斜め読みで終わらせた🤔
syossan2717章、Russ CoxってGoogle Code Searchにも関わってたのね
syossan27淡々と第４部読み進めてるが、実際問題モノリポってどうなんだろう？という気持ちが強くなってきた
syossan27依存関係に対する提案としてのLive at Head, 言わんとすることは分かるがOSS開発者とその依存関係に連なる開発者へのコストが高すぎてちょっと現実的じゃないかなと思ったり。
syossan27GoogleのLSCに対する文化が外界へ影響を与えた事象。RoseHub作戦。
syossan27ペットとして扱うコミット、家畜として扱うコミット。
コンテクストとしてはLSCなんだけどdepandabotとかも家畜なコミットかな。
syossan2716, 23章で出てきたversion skewについて（これくらいしか意味解説したの無かった…