チームに秩序をもたらす技術としての静的解析

開発やってて、前にも同じ議論した、同じようなことで迷った、同じようなことを聞かれたと思うことがたまによくあった。あるいは新規参画者がコードレビューで指摘を受けた理由がチームの決まりだからなんだけど、どこにも書かれてなければ誰からも教わってないので遵守しようもないよねみたいなことも。

方針やルールの類が見える化されてないと

• 新規参画者に伝わらない。
• 前からいるメンバーだとしても忘れる。

結果として

• 伝承コスト、修正コストがかかる。
• 改めて考えたり議論したりすることによって時間がかかる。
• なんなら違う結論に至って方針が（無意識的に）変わる。

でもって方針が一貫してないと、例えば、異なる書き方のコードが混在するなどの形で発露する。

結果として

• 不適切なコードを参考にした結果、修正するハメになる。
• どちらの書き方に倣うべきか迷って時間がかかる。
• 一貫性がなく読みづらい。

みたいなことが起きて生産性が下がる。

そこで、チームの方針を見える化すること、判断した形跡を残し、時間を超えてチームに関わるメンバーが同期し続けることによって、方針や判断に一貫性を持たせるのがよいのではないかと考えている。（完璧には難しいけれど）

そして、それを実現するためのツールには様々なものがあるのだろうけれど、3つあげるならば

• ガイドライン
• ADR
• 静的解析

だと思っている。ところで、ガイドラインは方針のキャッシュ、ADRは議論のキャッシュと捉えられそう。ADRほどかっちりやらないにしても、議事録やガイドラインに議論や決定事項の根拠を残すのもそれに近しい行為だと考えている。

で、やや不自然に付け加えると、僕は理屈ではなく静的解析の世界観が単純に好き。なんとなく好き。そもそも好き。それはそれとして、理屈で考えても以下のような点で有用だと思っている。

• フィードバックがはやい。
• 開発ライフサイクルの割と初期に不具合を検出できてコスト抑制効果が高い。
• 人の判断を介さずムラがない。
• （導入時はさておき運用時に）人の議論を介さず争いが起きない。
• （気のせいかもしれないが）人からよりも機械からのフィードバックを人はすんなり受け入れる。
• （特にはじめっから導入されてれば）あまり手間がかからない。
• ある意味方針が（自然言語じゃないけど）言語化、見える化されている。

みたいなことを思うなどしたので書き留めておく。