ryokatsu.dev

Googleのソフトウェアエンジニアリングを読んだ

年末年始の休みに入ってから読みはじめてようやく読み終わりました。（一部読み飛ばした所あり）

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

Team Geek

Team Geekという名著があります。本書でもこのTeam Geekで出てくるHRTの概念について説明しつつ、Googleがチームで仕事するために心がけていることが詳細に書かれています。

※自分もいいチームとはどういう状態か。というブログを書いていますので興味があれば読んでいただけると嬉しいです。

エンジニアリングマネージャとテックリード

この2つのロールは、双方協力する必要があると書いていました、エンジニアリングマネージャーはやはりピープルマネジメントをすることが主な仕事らしくGoogleでも同じなんだなと思いました。

スタイルガイド（ドキュメント）

ドキュメントは「書くのが簡単である」点より「読むのが簡単である」方が重要と書いてあってまさにそのとおりだなと思いました。どうしてもマークダウンで簡単に書けるとかに考えが行きがちになってしまうことがあって、これはもう少し深堀りすると「エンジニアはドキュメントを書きたがらない」という問題があるなと思っていて、できれば簡潔に済ませたいという心情がありそう。。

ドキュメンテーションの章で、Google内のドキュメントは、独自のWikiであるg3docというもので運用しているらしくどういう感じのツールなのか実際に触ってみたい。

テスト

とにかくユニットテストが大事とのこと。Google社内でも最初はテスト文化がなかったと書かれていて、技術者間での情報共有として有名なトイレに張り紙をするを行ったことで、文化が少し根付いたそう。

特に自動化の話は共感しかなかった。Googleに限った話しではないないですが、月に1件しかバグを出さないエンジニアでも、100人いれば1営業日に5件のバグが出ることを考えると自動化するのは当たり前と書いてあってまさにそのとおりだなと感じました。

コードは債務であり資産ではない

リファクタリングの章だったかでこの言葉が出てきて名言だと思いました。コードにはコストが掛かるのは当然で、コード自体には価値はなくコードが提供する機能自体に価値があるので定期的なリファクタリングは重要ですね。

Googleの様々なツール

本書は、エンジニアリングのこと以外にもGoogle内でエンジニアリングをするにあたり独自のツールを使って運用しているユースケースを紹介しています。色々面白いツールがあるなと思いつつ特に気になったの、はGoogleでのソースコード管理は、Piperというツールを使用しているらしく（chromiumなどの大規模ななもの以外）1営業日あたりに手動、自動合わせて6~7万回のコミットがあると書いてあって桁が違いすぎて驚きました。（Piperに関する論文）

全体の感想

正直最初は、どうせGoogleという大規模がやっていることだからな〜みたいな感覚で読んでいましたが、普段から自分が思っていること、感じていることが正しいかどうかを答え合わせてして確認するような書籍だなと思いました。おそらくエンジニアリングで必要な領域はほぼカバーされているので網羅的に読むのもいいですし、特定の分野の章だけ読むのもありだと思いました。（例えば継続的インテグレーションだけなど）

一番いいのは、章ごとに担当を決めて輪読会とかやると面白そう。