Googleのソフトウェアエンジニアリング

1章

ソフトウェアエンジニアリングとは何か
- プログラミングとの違い
  - 時間、スケール、トレードオフ
- 「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」
  - 立方体は正方形ではなく距離は速度ではない
- 時間がプログラムに与える影響を知る
  - コードの想定稼働期間はどれだけなのか
    - 大学の課題や研究、スタートアップのコードはそこまで保たない
- 行わなけれなならない決定とそれに依存する利害の複雑性
  - 不完全な価値のメトリクスしかない
  - トレードオフの評価を強いられる
- リーダー
  - 組織や製品や開発ワークフローのスケーリングを行うコストが持続可能で管理されている状態を目指す
- 保守性のある状態を保つ→不断の闘い
Hyrumの法則
- API←利用者の依存関係
- すべての観測可能な挙動に適用される
- 今動く≠無期限に動く
- ハックorクレバーではないコード
何も変化しない状態を目指す
- 変化の能力自体は必要
スケールと効率
- 変更は頻繁になるほど変更が容易になる
トレードオフとコスト
- Googleの自社分散ビルド→100年とかのスパンなら合理的そう
  - Next.jsのpage router→App routerも似ている気がする?
    
    課題があって解決したというよりも、今まででもよかったものをより良くしようとして複雑になったという印象が強く、選択を躊躇ってしまう要因になっているように感じました。
    
    フレームワークが決めていた項目をより良くする←→複雑さが増す
ソフトウェアエンジニアリング対プログラミング
要約

wikipedia

有用なソフトウェアが持つ特性・構造を探り、その構築・維持・管理に有用なプロセスを見出す学問

rrih

2章

チームでうまく仕事をするには
- 「早期に失敗し、高速に失敗し、頻繁に失敗せよ」
  - 1章で述べられていた内容の言い換え
    - 早期のフィードバックの重要性
  - 知識とノウハウはプロジェクト内になるべく分散させるようにするべき
  - 社交スキルの三本柱
    - 謙虚
    - 尊敬
    - 信頼
      - Google文化にもある
  - 失敗→ドキュメント化
    - 事象の簡潔な要約
    - 発見から調査を経て解決に至るまでの流れ
    - 主要原因
    - 影響と損害の評価
    - 問題修正の一連の処理事項
    - 防ぐための一連の処理事項
    - 得た教訓
  - 1人だけで仕事を進めることとチームで仕事を進めることの時間的トレードオフ

rrih

3章

知識共有
- 最重要→学びの文化
- 心理的安全性
  - 知らないことを表明することへの寛容
- 大規模集団での心理的安全性
  - 集団の交流のアンチパターンは意図せずとも出現しうる
    - 謙虚さが必要そう
- 文脈
  - ルールやスタイルガイドには文脈、背景など十分な情報に基づくべき
- 自分の知識をスケールさせる
  - 対面
  - 講習
  - コード
  - ドキュメント
- 組織の知識をスケールさせる
  - 成果物より文化と環境
  - インセンティブ
  - Googleでは社内専用のURL短縮ツール(goリンク)で知識共有が行われている
- 知識共有は複数の戦略の組み合わせが必要、配分は時間の経過に伴って変化する

rrih

 4章
公正のためのエンジニアリング
万人のために開発をするな。万人とともに開発せよ
システム全体で公正さを計測せよ
単一のユーザーの要求を満たすと他のユーザーの権利を損ねる場合があるので多様性、公正を持つチームを組む

バイアス=デフォルト状態



 5章
チームリーダー入門
伝統的な意味での管理は行うな
可能な場合は委譲せよ



 6章
スケールするリーダー
曖昧な問題を解決するための最良の答え=色々な方面のトレードオフが存在する
自分を単一障害点にしない



 7章
エンジニアリング生産性の計測
速度の計測の際に品質の計測を忘れない(逆も然り)
QUANTS(コード品質、エンジニアの注意、知的複雑性、テンポ、満足)

データ駆動で主観的バイアスを排除を目指す
結果に対して何もできない場合計測に価値はない



 8章
スタイルガイドとルール
ルールを作る際の質問「どんなゴールを前進させようとしているか」
なぜそれがルールになるのか説明できる必要

明示的なルールは不要なオーバーヘッドが入ることがある
ルールの強制は自動化

このスクラップは9日前にクローズされました