ソフトウェアの「悪い方が良い」原則の例

https://gyazo.com/210f0b4b0e2a5b1024348831ac54f183

悪忌の守護神

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。

(中略)

lld v2の成功のすべての原因が「悪いデザイン」だったとまでは言わないけど、それが大きな要因になっていたのは間違いない。だから「悪い方が良い」原則をここで再度強調してみてもよいだろう。「賢いやり方」や〇〇原則といったものにこだわりすぎないこと。実装の単純さはとてもとても重要で、そのためにはレイヤ分けの一貫性や完全性、コード重複の少なさを、リーズナブルな範囲で犠牲にしてもよい。自分が良いと思うデザインで小さくて実際に動くものを作り、それを次第に育てていくことが大切だ。

ソフトウェアの世界に入り、様々な書籍やWeb記事、同僚の教えを得て「XXの法則」や「XX原則」を知ると、その知識を「良いデザイン」と認識して使いたくなる

多くの良いデザインとされるものは、全ての環境・状況でいつでも採用すべきオールマイティなものではない。

プロジェクトメンバーの中で数人しかわからない正しい設計よりもみんながわかるダーティな設計のがスケールするんですよね

悪いと言われる設計のほうが多くの人にとって分かりやすく、扱いやすく、広がりやすかったりする

良いと言われる高度な設計は理解するのが難しく、メンテナンスコストも高くてスケールしなかったりする

- 愚直なコードのほうが、「賢い」コードよりもずっといい

- 近道だと思ったものは、長期的にみると近道でないこともある

- 自分の主観でリファクタリングしてしまう開発者に注意

etc.