Software Engineering at Googleの1章を読んだ

<br />

Software Engineering at Google: Lessons Learned from Programming Over Time
を読んでるマスタカです
気持ちはマスタカもGoogleにいるエンジニアだ！

1章はソフトウェアエンジニアってなんだろなって話

・ソフトウェアエンジニアリングとプログラミングの違い
プログラミング：開発
ソフトウェアエンジニアリング：開発、変更、メンテ

・ソフトウェアエンジニアリングとプログラミングの違い2
ソフトウェアエンジニアリングはさらに以下を考慮する
持続可能
スケール(チームでの開発)

そして、ソフトウェアエンジニアリングのリーダーの仕事は
持続可能で組織をスケールできるようにすること

持続可能
・持続可能とは
変更すべきものごとに対して安全に変更可能であること

・Clever
プログラミングでは褒め言葉
ソフトウェアエンジニアリングでは断罪される行為

・ライブラリのfork
短いスパンのソフトウェアならforkして作っても良いが
長いスパンのソフトウェアでforkは避けるべき
特にデータ構造やシリアライズのフォーマットやネットワークプロトコルは避けるべき

・ソフトウェアのアップグレードが大変な理由
完了してないプロジェクトなので、隠れた問題がある
エンジニアは、ソフトウェアのアップレードの経験は思ってる以上にない
また、アップデートは大きくなりがち(数年に一度しかやらないのも理由)

・Hyrum’sの法則
APIに十分なユーザがいる場合、
APIの仕様書ではなく、観測される振る舞いに誰かは依存してる

・Churn Rule
infraのアップデートに対して
ユーザは自分たちで新しいバージョンに移動させるか自分たちでアップデートさせる

・Beyonce Rule
CIで検知できないエラーは自分たちのミスでない

これすごい、今すぐ採用したい(・ｪ・｀)

スケール
・スケールさせるためにやるべきこと
自動化(一人の人間ができることを増やす)
統合と一貫性(問題の範囲を狭める)
専門(2,3人の人間ができることを増やす)

・問題の解消時期
なるべく早期に見つけた方がコストが安い

・コストとは
金
リソース(CPU)
人的コスト(エンジニアの努力)
トランザクションコスト(行動を起こすこと)
機会コスト
社会コスト(その選択は、どんなインパクトを社会に与えるか)

・Jevons Paradox
リソース浪費は、効率化があがるのに合わせて増える。

全社共通のビルドシステムがあれば
依存を小さくしたりする動機が働きにくくなる

ソフトウェアは長い期間生きるのであれば
丁寧にスケールしやすく作ろう
ってことがよくわかりました
表にサービスとして出すものはできるだけそういう意識で作っていきたいですね
続くよ

<br />