8章 スタイルガイドとルール
8.1 何故ルールを設けるのか
Googleのスタイルガイドの多くは社外版があり
素朴な疑問として、何故社外に公開しているのだろうか
JavaのスタイルガイドはGoogleのものを採用することが多い
コミュニティが育ててくれる話が後で出てくる
かくしてルールは、共通の開発パターンを望ましい方向へと推し進めるための広範な影響力を与えてくれるのである
文化形成におけるルールの重要性がずっと書いてある
属人性がないので組織の文化として残りやすい
逆に、皆が当たり前に行っている良い習慣をルールに変えていくことも大事かもしれない
失われたと思ったときにルールにする
8.2 ルールを作る
当たり前での話ではあるんだけれど、まずはルールを作る理由から議論しているというのはこれまでの章の流れからしても納得感があるし共感がもてる
2億行以上のコードが入ったコードベースに向けて、約6万回のコード提出が毎日行われている。
こう言われると確かにルール大事だ
何かが明示的に違法となっていないというだけでは、そのことが合法であることにはならないのだ
メンバーと共有している「常識」って大事
それを見られるような採用フローにするのも大事
コードの作者より読者に向けて最適化する
この考え方がいい。前もどこかの章で似たような話があった気がする。
コードレビューのところで「コードは書かれるより読まれる回数が多くなる」とありました
ここで価値がある部分は、答え自体というより、答えが1つであるという一貫性である
重要な点は、任意のルールに何を選んだかではなく、むしろ選択を行ったという事実である
「決めの問題」をなるべく決めておく、ということ
無益な議論を避けるために重要
最初から気付くのは無理なので、ルールを育てるのが必須っぽい考え方
コード管理人
これはなんだろう
スタイルガイドのオーナーとの対比で、目の前のコードのオーナーってことが言いたいのかな?
ソフトウェアエンジニア以外の役職の人、らしい
そのコードをpushする以外の人
code janitors (ビルなどの管理人)。リファクタリングする人?
一貫性の階層
8.3.3に「我々のルールは法である」との記述がある通り、法律の運用プロセスを参考にしているように感じる
憲法>法律>都道府県条例>市区町村条例
運用(行政)、立法のプロセスも書かれている
少しだけ司法(スタイル調停者)も書かれている
我々のスタイルガイドには、まだ十分に理解されていない新しい言語機能についての制限も入っている
「禁止」ではないのがミソのようだ
「制限」することで、あえて使いたくなる効果がある
少し後ろの記述で「観測される事例からベストプラクティスを抽出する」とあるので、あえて制限することで使わせて、それを壁打ち代わりにしているのかも
JavaやTypeScriptみたく言語機能がどんどん新しくなると、スタイルガイドの更新も大変そう。TypeScriptはモダンな書き方に興味がある人口の比率が高いけど、Javaは比率ではすくないので更新するモチベーションを保つ人たちってごく一部になりがちになりそう。。。(Open JDKコミッターがいる企業で主導してほしさがある。。。)
古い言語機能は知らない間にdeprecatedになっていて言語バージョンを上げるのに難儀することになる
実装パターン味を感じる項だった
8.3 ルールを変更する
各プログラミング言語について、長年の経験を持つプログラミング言語の専門家グループがスタイルガイドのオーナーであり、意思決定者として任命されている
意思決定者を経験年数で決めているっぽいのは、言語の移り変わりを把握しているからとかなのかな?
経験年数の少ない人だとモダンな方向に倒しそう
8.2.1.6や8.3.3に過去のコードをそのままにするメリットについて書かれている
既存のスタイルガイドに関する決定の背後には詳細な根拠があるため、再評価を行って現在は異なる結論がより合理的かどうか確認できる
スタイルガイドには根拠もセットで記入されている模様
ルールが形骸化して時には儀式にすらなるの、これがされてないからだよなあ
変更提案を受け入れる根拠にも却下する根拠にもなるので良さげ
過去の問題と新しい問題を同時に解決するスタイルの提案か、過去の問題が陳腐化していて現在の問題のほうが深刻であることを説明できればacceptされる。合理的
スタイルガイドだけでなく、コードフォーマッターの設定ファイルにもコメントで記述しとくと良いかも、と思いました
エンジニアのコミュニティの者たちこそが、ルール変更の必要があるかもしれない場合に気づくのに最良の立場にいる
そういうことか!!
OSSのいいところをうまく社内に取り入れていて凄い
GoogleでもPythonのガイドラインで最初にキャメルケースを入れてしまうみたいな失敗があって、かなり時間が経ってからじゃないと直らないっていうのは、なんというかGoogleでもそうなんだなっていう気分と、そういうところは政治っぽいんだなーっていうのがあって、テクノロジー超得意な大企業っていうのがわかる気がする。決まったことはめっちゃスケールさせるのが得意なんだけど、変更するのはたくさんの人間の意思決定が必要でその辺はふつうの大企業だなっていう。
決めたことをとにかくやる、できるだけテクノロジーで解決する
人治になるのを避けようとしている感じがある。なので本当に意思決定が必要な場合は全員の納得を必要にしてハレーションを避ける。テクノロジーでの解決に倒すのも同様(ハレーションを避ける)の考え方
8.4 ガイダンス
「今週のヒント(Tip of the week)」シリーズは社内で大変に成功を収めており、コードレビューと技術的議論の最中に頻繁に引用される
いい!!
というかこの章全部いい
めっちゃわかる。ソフトウェア工学の関心がかなり溜まっている領域だと思うし、読んでいて楽しい。
8.5 ルールを適用する
gofmtまわりは出た当時は反対派もそこそこいたけど、いまやフォーマットは標準があるほうがいいってことにほとんどの人が同意しているし、ゆえに自動修正系のツールやChatGPTによる生成もしやすくなっているっていうのが本当にすごい。機械にも人間にも優しいデザインにすることのメリットが極まっている感じがする。
ツールに多くを移譲すればするほど、人間のバイアスの介入を許していた入り口の数を減らせる
これChatGPTだと怪しいかもな、と思いました。一貫性を持たせられるように訓練したら大丈夫なのかしら
90%のルールが自動的に検証可能であるという推定が出た。
へええ。面白いデータだし、こういう調査がおそらく日常的に行われているっていうのはすごいなあ
8.6 結論
8.7 要約
ちょこちょこ「ツールではまだ無理だ」っていっているところが、ChatGPTではできてしまうようになってきていて、それもこういった礎があったからだなーって思うと感慨深いのと、ChatGPTすごい。。。ってなった。
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
時間とスケーリングに対する情熱?が高いから。
現場でどこまでできているか?
どうしても各プロジェクトや事業部の秘伝のタレ化してしまっていて、全社としてナレッジベースの運用やOSSのようにリポジトリを育てるみたいなことに踏み出せていない
昔は社内標準を一部のトップエンジニアが定めていたが、OSSのようにみんなで育てるようにしていきたい
有名ツールをとりあえず入れるっていうのは、大抵できている気がするけど、更新するっていうのがイマイチな気もする。
この本があるのになぜ実践する企業はすくないのか?
コードにおけるスクラムマスターみたいなロールがあまり明確に言われていないとか、価値のある自動化ツールを開発するっていうほどの技術力がないからとか。
cf.) Code janitor
それの乗り越え方はなにか?
いわゆるツールがもっと便利になるのを待つっていうのはありそう。自分たちでやるっていうわけじゃないけど、GitHubやIDEや静的解析ツールにChatGPTが組み込まれれば比較的簡単にやれる気もする。
一方で現状のツール群ですら導入できていない人たちをどうやって変えるか?っていうのは既存のコードに対してのことが多い気がしていて、やはりこういうコードの変更に対してのテストをどれくらい自動化できているかっていうのは大きそう。単なるスタイルの変更だとしても、スタイル以外の変更をしていないことの検証にはテストが必要になるっていう。。。
あと、スタイルは一部だけ変更っていうのがしにくい(読みにくくなる)のでそういった意味でも大変だなっていう気がする。せめて、デプロイする単位では統一されていて欲しい。
ステップを小さくするとしたらどうできそうか?
小さいプロダクトだけでも実践して効果を定性的にでも継続的にまとめて、モチベーションをつくるとか?
まずはコードフォーマッターの導入
自然にデフォルトのルールに不満が出てくるので、変更や調停が必要になる気がする