第3部: プロセス ふりかえり
コード自体は債務である
この箇所は第3部のハイライトの一つだと思う
「廃止」でも触れられていたし、テストに関する章ではテストコードの負債ができるだけ小さくなるよう注意を払うことに紙幅が割かれている
コードレビューは、組織の至るところでの知識共有のために重要である。
コードレビューの文化が無いところは、属人化していたり、自分が書いているコード以外に興味がない所もあったりするように思う
積極的にコードレビューをしている組織は、風通しの良さやチームワークの高さを感じる
余談だが、自分は転職活動で会社を受ける時、コードレビューをどの様にしているか聞くようにしている
コードレビューをやってるかどうかはコードにチームとしてオーナーシップを持っているかどうか
立ち止まって品質を高める行動をするかどうかは組織の健全性を表す
例:「外注さんが作ったコードが汚いから書き直している」⇒健全な活動できてなさそう・・・
ドキュメンテーションに行われる投資は、長期的には回収できる
長期的には回収できるとしつつ、Whoを特定し、目的を専念することで投資対効果をあげていく。(自分自身のためでなく対象読者に向けて書くべきというのがGoogleっぽくてよいなと感じました)
この章だけ泥臭い
質の良いドキュメントをコードに追従して生み出し続ける方法論がGoogleでもまだ確立されていないことがわかる
確立されていたら、フローをある程度強制するアプリケーションが出ているはず
そういえば「ドキュメントの質が良い」ことで有名なプロダクトってない気がする
「万人に読みやすい文章」は存在しないのかも
AWSのドキュメントは使ったことがない人にはわかりづらい
Google CloudはGetting Startedの質が高いが他は……
個人的に第3部の中で特に印象に残っている
現代のソフトウェアシステムの規模と複雑性に対応するべく劇的な進化を遂げてきた。その進化の中核に位置してきたのが、開発者主導の、自動化されたテストのプラクティスである
「開発者主導」という部分がよい
自動テストがGoogleの中核という印象
t-wadaさん他結構この書籍のこの章引用してる人がいる気がする
目新しさはあまりなかったが、前章のテストピラミッドでユニットテストは80%を占めていることからも基本だし大事
DRYではなくDAMP
印象深い一節
DAMP: Descriptive And Meaningful Phrases
権威主義でほんとは良くないんだけど、テストコードの複雑さの話になったときに引用したことがある
テストの循環的複雑度を1にしよう、という話も出た
この章の回で「古典的テスト」と「モック主義者テスト」の話があって勉強になった
ロンドンとデトロイト
この章だけ粒度や内容がちょっと浮いている、との指摘あり
ベストプラクティスでなくトレードオフについて書かれている
Googleでの扱いではなく教科書的な内容
テストの規模やプロセスでなくツールの話
APIやアーキテクチャの境界面でのテストダブルについて考えるのは面白い
仕様を決めた瞬間に自動生成されるのが良い
Swaggerは上手くいっている仕組み
yamlなどでJSONを返すWeb APIのスキーマを設計できる
思想として、サンプルデータを一緒に書くようになっている
クライアントライブラリ、スタブの生成ができる
RDBでもスキーマ生成したら勝手にテストデータを生成してほしい
毎週何千ものカオステストを実施
大規模テストで急に今の自分たちとGoogleの違いを感じた。
テスト戦略を理解した上でビジネスとの天秤にかけて実行していくところが出来ない。まだまだ自分たちは開発とビジネスに隔たりがあるんだろうなと思った
大規模テストには、ドキュメントに記載されたオーナーが存在しなければならない
組織的な成果物には必ずオーナーを置くのがGoogle流のようです
「廃止」自体にわざわざ触れるのは珍しい
ソフトウェアエンジニアリングの本というと「いかに作るか」に焦点を当てがち
この本は「いかに運用するか」に焦点が当たっている
コードは債務であり資産ではないという基本体前提から始まる
Googleくらい多産多死だから書けた章