生涯未熟

生涯未熟

プログラミングをちょこちょこと。

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

www.amazon.co.jp

を読みました。ソフトウェアエンジニアリングを広範に取り扱っためちゃくちゃ良い本だったので、下の連ツイを基にちまちま感想などを書いていく。
※ 684ページという大ボリューム＆プライベートで様々なイベントがあったので読むのに3ヶ月ほどかかりました・・・

どんな本だったか？

さっくり言うと「ソフトウェアリングという広範的な物事における考え方・やり方をしっかり学べる本」になります。
全体構成としては５部に分かれており、

  1. 主題
  2. 文化
  3. プロセス
  4. ツール
  5. 結論

となっています。

主題では「ソフトウェアエンジニアリングの定義・著者が発見した法則・時間的変遷による事象」などを絡めつつ、この本の前哨戦として何を学んでいかなくてはいかないのか？を説明されています。
文化は「メンバーとして、またリーダーとしてどういった文化を築かなければならないか」、プロセス・ツールでより具体的なスタイルガイド・コードレビュー・ドキュメンテーション・テストなどなどの話。
そして結論、という流れでソフトウェアエンジニアについて過不足なく学べる内容だったと思います。

個人的にどこが良かったか？

"Googleの"と銘打っていますが、「Googleではこんなクールなやり方をしているぜ！」といった本ではなく、最初期のGoogleが我々と同じような苦しみを抱え、時には失敗し、その結果どういったやり方に帰結したか？という流れをキチンと説明されているところがとても印象が良かったです。
3部 14.1.2.2 設定の問題にて、「Googleでは設定変更が大障害の原因の第一位である。」とあるように、誰もが経験することを勿論Googleも経験しているしそれが重大インシデントに繋がりこういった事故を起こした、といったことが赤裸々に書かれています。
Googleも人並みなミスを今までしてきた。ただそのミスをどういった考え方・やり方で根絶しているのかという流れは、自分自身に翻ってみても活かせることでしょう。

響いたところ

ここからは本書内で響いてメモったところを書いていきます。全部が全部を書いているわけではないので、気になった方は買って読んでみてください。

独自の法則

Hyrumの法則

APIに対してどういう契約仕様で作られたかをユーザーは考慮せず、ただ振る舞いに依存する。
つまり、設計者の意図を考慮せずにユーザーは利用する、ということであり"仕様"と"振る舞い"の乖離が大きくなればなるほど設計者とユーザーの距離が遠くなっていく。

このことによるデメリットは時間的経過によってより甚大なものになるのは想像に難くないでしょう。本書ではこの法則が様々な観点からちょこちょこと登場してきます。

Beyonceルール

「そんなに好きなら(≒ 破綻して欲しくないなら)そいつにテスト付けときゃよかったのに」
ミッションクリティカルであるなど、破綻が許せないなら必ずテストしましょうというルール。特にインフラストラクチャの文脈で語られるルールです。
インフラストラクチャの変更で何らかの障害が起きるといった可能性はありますが、それをCIで防げないのであればCIの落ち度であり変更には全く責任が無いとも言い換えることができるでしょう。

リーダーとは斯くあるべきか

チームリーダーについて語られている章は、個人的には本書内で熟読する価値が非常に高いと考えている一つで、「何をしなくちゃいけなくて、何をしてはいけないのか？」が書かれています。

リーダーが負う責務

「リーダーはプロジェクトの要所要所においてトレードオフを明確化させ、それをどのように行うべきかの決定における責務を負わなければならない」。これには非常に納得でした。
リーダーが決定に対して責務が負えないのであれば、チームとしての迷いが常に漂ったまま仕事をし続けなければいけなくなり非常に不健全です。メンバーに意見を乞うことは積極的にしなくてはいけませんが、決定は必ずリーダーがやるべきものです。

逆に「リーダーは完璧超人であるべき責務は負わなくていい。またその振る舞いをしてはいけない」、とはっきり書いてあります。それよりも、合意形成をよりスムーズに行うための"触媒"であったり、適切な答えを知っている人を知っている、といったサポート役としての振る舞いが重要視されます。

去れるリーダーになろう

あと面白いなーと思った考え方は第2部 6.2に書かれている「いつでも去れ」です。私も常々思っていたことですが、「自分が明日事故に遭い、働けなくなった場合にこのチームは何も支障なく回り続けられるだろうか？出来ないなら何が必要だろうか？」という考え方です。本書ではそういった考え方を"バス係数"と呼んでいます。
「プロジェクトが破綻するのに要するプロジェクト内でバスに轢かれる者の人数」がバス係数で、自分やメンバーがバス係数としてカウントされないような自律的組織を目指しましょうといった流れで解説されています。自分がいなくなっても回るように整備し、自動運転できることを見届けたら去り、また別のチームを整備していく・・・目指すべきリーダー像のひとつですね。

ブログの下書きに入れっぱなしになってたので、一旦公開。
また読み返した時に追記します。