エンジニアの皆さん、お疲れ様です。
日々、「良いコードを書こう」「クリーンコードを心がけよう」と、半ば信仰のように語られる「良いコード」という概念。本当に、それは絶対的なものなのでしょうか？
私は声を大にして言いたい。「良いコード」の定義なんて、幻想に過ぎない！ そして、可読性や保守性を過度に追求することは、むしろ開発の足かせになることさえある、と。
この記事では、私が長年の開発経験で感じてきた「良いコード」神話への疑問と、それにつきまとうワナについて、あえて過激な表現でぶった斬っていきたいと思います。異論は認めます（むしろ歓迎します）。
1. 「良いコード」は宗教である
DRY原則
SOLID原則
単一責任の原則
コメントは書くな、コードで語れ
変数名は分かりやすく、関数名は簡潔に
これらはまるで宗教の教義のように語られ、多くの現場で絶対視されています。しかし、これらの原則は、本当に常に正しいのでしょうか？
その裏には、開発者のエゴや、思考停止を生む危険性が潜んでいるのではないでしょうか。
2.「可読性」という名の欺瞞
誰もが口にする「可読性の高いコード」。果たして、それは誰にとっての可読性なのでしょうか？
ベテランエンジニアにとっての可読性 ≠ 新人にとっての可読性
ベテランは抽象化された簡潔なコードを好むかもしれませんが、新人にとっては複雑怪奇なマジックにしか見えないことも。
「コードで語る」は本当に正義か？
確かに不要なコメントは悪ですが、複雑なロジックやドメイン知識を伴うコードにコメントを一切書かないのは、もはや嫌がらせではないでしょうか。
コメントがないために、何日もかけて他人のコードを解読する羽目になった経験、ありませんか？ それ、本当に「可読性」が高いと言えますか？
3. 「保守性」が開発速度を殺す時
「将来の保守性を考えて設計する」—これもまた、多くのエンジニアが陥りがちなワナです。
過剰な抽象化は諸悪の根源
「将来拡張するかもしれない」という漠然とした不安から、やたらとインターフェースを切ったり、汎用的なクラスを作りすぎたりしていませんか？
その結果、コードは複雑になり、変更するたびに芋づる式に影響範囲が広がり、むしろ保守性が低下していませんか？
使われるかどうかも分からない未来の機能のために、現在の開発速度を犠牲にしているだけではないでしょうか。
本当に「将来」は読めるのか？
3ヶ月前の自分のコードすら思い出せないのに、数年後の他人が書いた（あるいは自分が書いた）高度に抽象化されたコードが、本当に「保守」できると言い切れますか？
4. では、「動くコード」以外に何が必要か？
結局のところ、ユーザーにとって価値があるのは「動くコード」だけです。そして、そのコードがビジネスの要求を満たし、迅速に価値を提供できることこそが、最優先されるべきではないでしょうか。
私が考える「良いコード」は、究極的には以下の3点に集約されます。
①動くこと: 最低限にして最高の要件。
②目的を達成していること: ビジネス価値を提供できているか。
③チームの合意があること: 特定の誰かのエゴではなく、チーム全体で「このレベルで十分」と合意できていること。
もちろん、品質やテストの重要性は否定しません。しかし、それらはビジネスのゴールを達成するための手段であって、目的そのものではありません。
5. あなたにとっての「良いコード」とは？
「そんなことはない！」「何を言っているんだ！」と思った方も多いでしょう。
むしろ、そう思ってくれたなら本望です。
この問いは、エンジニアリングにおける永遠のテーマかもしれません。
しかし、私たちは一度立ち止まり、「本当にその原則は、私たちのプロジェクト、私たちのチームにとって、今、最適なのか？」と自問自答すべき時が来ているのではないでしょうか。
あなたの考える「良いコード」の定義をぜひコメントで聞かせてください。