X(Twitter) Zenn GitHub RSS 共有

「何故」を書け

作成日時:2024-08-01以前
更新日時:2024-08-01

要約

ク●コード滅ぶべし。

小噺

料理の先生「今日は美味しいイチゴのショートケーキを作ります。」

生徒「はい。」

料理の先生「材料はイチゴ、生クリーム、豚肉。」

生徒「豚肉?」

未知はストレスである

豚肉を何に使うつもりなのか。
異質過ぎて説明が頭に入らないし、調理のビジョンも湧きづらくなる。
何か意図がある可能性もありうるので、容易に豚肉をレシピから外すこともできない。

ク●コードまみれの現場もこんな感じだと思っている。
明らかに不要なのに、副作用が怖くて弄ることができないク●コード。
無駄に怯え、無駄に検証し、無駄に時間と脳のリソースを浪費して改修する。

人間は不確実性/曖昧性/未知にストレスを感じる。
意味不明なク●コードは存在だけでストレスを与え、認知負荷を上げる。
つまり無駄に脳味噌を使わされる。
そして動きの鈍くなった脳味噌で更にク●コードを書いてしまう。

ク●コードがク●コードを呼ぶ悪循環となる。

我々は頭脳労働をしている。
それなのに脳に負荷を掛けてどうする。
肉体労働に例えれば、手足に重りをつけて作業をしていることと同義である。

参考:割れ窓理論 / 驚き最小の原則

「何故」が分かれば動ける

料理の先生「豚肉のしぼり汁を生クリームに入れれば、生クリームから豚の臭いを出せます。」

と、理由を言ってくれればこちらはどうとでもできる。

「今日作るケーキに豚の臭いは不要だから豚肉は取り除こう。」
「この先生は頭がおかしいから他のレシピも検証しよう。」

つまり
「今回作るサービスには全く関係ないからこのソースの記述を削除しよう。」
「この人の成果物は怪しいから全部再検証するか。」
とか出来る。

「何故」が無かったら何もできない。
ク●現場はだいたい成果物に「何故」がない。
何をしているかしか書いていない。(しかも設計書は実装とあってない)
そしてプロジェクトから人が抜け、知識はロストし、後に残るのは誰も説明できないク●コードのみである。

「何故」を書け。
ドキュメントには「何故」を書け。

まとめ

推測可能な文章は読みやすい
豚肉が推測可能性を破壊している。