20章 静的解析
Googleは静的解析を通じて、ベストプラクティスをコード化し、コードが現代的なAPIバージョンへ合わせて更新され続けるように促し、技術的負債を防ぐかあるいは減らす。
まじか。。。凄い。マイナスを見つけるだけでより良くするみたいな使い方は出来ていない。
これどういうモチベーションというか動機づけが成功しているのか興味深い。
20.1 効果的な静的解析の特徴
解析類型に追加する新規項目のコントリビュートは、全社から募集している。
Googleはこういうところが上手な気がする
ツールのスケーラビリティはこの書籍通して繰り返し出ていて、一貫しているなって思うんだけど、そのときにスケールさせつつも有効に機能するようなアイディアを出せるのがすごいなーっておもう。もちろん一発で出たわけじゃなくて試行錯誤が多いんだろうけども。
20.2 静的解析を機能させる際に鍵となる教訓
静的解析ツールのユーザーと開発者との間のこうしたフィードバックループを育むことにより、ユーザーの信頼の確立と社内ツールの改善につながる好循環が出来ている
はぁーーー凄い。社内ツールって融通が効かないしホスピタリティが低いどうしようもないものっていう環境で育ってしまった。
社内ツールでもユーザーのフィードバックをもらえる状況にしているって、徹底していてすばらしい。。。当たり前のことをやるんですよ。って言われているような気がした。
社内ツール、作りっぱなし&運用責任が不明確な場合が多いですよねえ
社内ツールは銀の弾丸のように思われがち
モノリポによる通常の開発フローへの統合、静的解析ツール専門チームの存在が大きいと感じました
開発者がツールの利用を実際に望むようになるには、誤検出率の低さがしばしば決定的に重要となる
うっかり八兵衛 vs. オオカミ少年
と書くと、誰もが「八兵衛のほうがマシ」というはずなのに検出漏れに目が行ってしまうのはなぜだろう
作る側からすると測定しやすいから?
漏れている場合は「見たら確実に意味がある」のは担保できるが、嘘ばっかりの場合は徒労になるので見なくなる
ここを運用まで落とし込んでいるのがすごい。普通は気付いたところで満足する
静的解析を中心的なワークフローに統合
静的解析ではないが、LLMの登場でワークフローの見直しって生じているのだろうか。copilotのようなIDEのAIアドオンは必須みたいな。
20.3 Tricorder:Googleの静的解析プラットフォーム
スケールさせるために、Tricorderはマイクロサービスアーキテクチャーを用いている
当たり前のように書いてるけど、凄い
何故その解析結果が役に立たないかについてアナライザーを書いた者に対して直接バグを提出するという任意選択機能のUIが出てくる
フィードバック、先延ばしにしがちなのでこの仕組みは強い
先延ばしのしにくさ = (期待 * 価値) / (個人の衝動性 * 価値を手にするまでの時間)
一番解消しにくい「時間」を仕組みで解消し、積み上げてきた信頼が解消の期待を大きくする
一方で、心理的安全性が担保されないと気軽に実装できない仕組みでもある
クソリプがたくさん飛んでくると、開発者が疲弊してやらなくなる
ユーザーによるカスタマイズ機能があることで、隠れたバグが生じると共に、ユーザーからのフィードバックが抑止される結果に終わっていた
寓話のような話
「警告を出す機能」全般に言える話で、オンオフの自由度を適度に狭めることでフィードバックを得やすくなる、ということかも
このカスタマイズ機能を成功に導く鍵となった卓見は、ユーザーレベルのカスタマイズ機能ではなく、プロジェクトレベルのカスタマイズ機能に的を絞ったことだった。
これめっちゃ洞察が含まれている。良いデザインとはなにかっていうのがつまっているなー。
20.4 結論
全体通してですが、こういう積み上げがあっての、GitHub Copilotとかなんだなーってしみじみと思いました。Tricoderでの修正提案とかもまさに。
20.5 要約
静的解析を中心的な開発者ワークフローの一部とせよっていうところ、ほんとうにそうおもっていて、いまの仕事でも領域問わずそうしている感じがある。エンジニアリングたのしい。
手でチェックしているとどれくらい時間がかかるのか、人間がやり続けるとどの程度見落とすのか、一旦試算する
ユーザビリティや実現可能性(フィージビリティ)があるかどうかも一緒に検討する
UIは皆が使っている既存のツールとなるべく合わせる
問題自体の検出
名前とバグの関係を見る。各所で使われている単語の統一性
Powerpoint のLinter; NPOIライブラリを使う
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
独自の静的解析ツールを開発し、専用のチームで運用しても十分にペイする会社の規模
こういうのを小さくてもいいからつみあげていくのが本当に尊い
ビルドのところにあったように、徐々に規模が大きくなってつらみが増して自動化、の流れ?
静的解析ツールの全社展開と継続的な改善が有用な投資であると判断できるマネジメント
フィードバックを得やすい仕組みを作ってもクソリプが飛んでこず、心理的安全が担保されるメンバーの質
会社として良しとしない文化も大事
自分たちが導入したものをメンテナンスし続けるオーナーシップ
現場でどこまでできているか?
「Linterで、既存のどのルールを取り込むか」は議論できているが、独自開発するところまでは全く行ってない
しかもやれているのはサーバーサイドのrubocopのみで、フロントエンドのESLintでは全然
常にはできていないし、自分のまわり2、3人だけでやっている感じがあり、これをスケールするにはどうしたらいいのかは思う。仕事の中心的なワークフローにするっていうのが大事だと思う一方で、エンジニアリングスキルがそこそこ必要だったりする。でも、いうほどそんなに必要ないかも。
正規表現はみんなが知っているが、parserは関数型言語を知っている人にしかメンテできないのでハードルが高くなりがち
この本があるのになぜ実践する企業はすくないのか?
「ペイする会社の規模」自体がかなり大きく、かつ測定が困難
スケールさせるのはモノリポでも相当難しそうだが、多くの会社はそうですらない
これほんとうにそうおもう。いわゆるPlatform Engineeringチームにまかせたい部分な気はする。
鶏と卵問題みたいな感じで、問題を小さくすることができないとかはあるかも?プラグインをつくったり、PRをつくるくらいはできてもいいのになっていうのはありそう。
でも、これも不思議な話で、機能追加における技術的負債はつみあげるし、その結果として儲かっていないこともあるんだけど、確実に効果がでそうなこういったところへの投資はさけられがちっていう。売り上げが足りない事業が多いってことなのかもしれませんが。
静的解析の推進に投入されるのって基本は人件費(有料のLinterはあまり聞いたことない。自分だけ?)で、そこへの投資判断をするのは現場判断なので、静的解析への意識を高く持っているPjMやEMが持つ権限の範囲でしかスケールしない、ということはありそう
CTOなんかが推進するにしても、地味なので活動としては忘れられがちだったり
Platform Engineeringチームがあるような組織なら、自然にスケールできそう。そうでない会社はチームに閉じがち
それの乗り越え方はなにか?
静的解析がどう有用で、いかに治安維持に役立つかを草の根で浸透させる
既存のLinterにはカスタムルールを入れられるものがあるので、それをできるだけ多くの人に実装してもらう
カスタムルールを社内ライブラリとして切り出して広報活動
気軽なフィードバックの動線を設けておく
GitHub のTeamを設けておいて、そこにメンションしてもらう
週次のMtgで静的解析でなんとかしたいことを言うコーナーを設ける
ステップを小さくするとしたらどうできそうか?
既存のLinterを入れ、ルールを自分たちでメンテする習慣をつくる
これが一番簡単そう?
Chrome拡張とか、PowerPointみたいなちょっと別の部分でも静的解析をいれるツールをつくってみるとか
特定のURLで特定のチェックが走るようなChrome拡張