わたしのエンジニア人生はクソコードとの戦いだった
はじめに
エンジニアとして仕事をしていると、「なんなんだこのクソコードは…」 と考えさせられる場面に多く出会います。
理解しがたい命名、統一されていないコードスタイル、複雑に絡み合った条件分岐、ハードコーディングされたパスワード——
こうした「クソコード」と向き合いながら、日々開発を進めることは決して珍しくありません。
なぜ、このようなコードが生まれるのでしょうか？
そして、どうすれば「読みやすく、保守しやすいコード」を書けるようになるのでしょうか？
これまでの経験を振り返りながら、その答えを探っていきたいと思います。
クソコードとの戦い
私がこれまで直面してきたコードの一例をご紹介します。
意味不明な関数：「hoge()」などと適当なネーミングされた本番コード
統一感ゼロのコードスタイル：スネークケース・パスカルケース・キャメルケースが混在
コメント皆無の巨大ファイル：無駄な変数や関数が散乱する8,000行超のソースコード
謎のコードコメント：「// 変更禁止」と書かれているが、なぜか理由が書かれていない
ORMの存在意義を無視：TypeORMを導入しながら、なぜかSQL文を直書きする実装
Vue3環境でのVue2流儀：Nuxt3(Vue3)を導入しながら、Options API(Vue2)の書き方を踏襲
このようなコードが蓄積されると、開発効率が著しく低下し、バグが増加し、プロジェクト全体の生産性が下がってしまいます。
なぜクソコードが生まれるのか？
私が考える主な要因は、「コードの品質に対する意識や余裕がない」ことにあると考えています。
特に、ウォーターフォール型の開発では、あらかじめ決められたスケジュールや予算を守ることが最優先されるため、開発現場では次のような悪循環が生まれがちです。
- 納期を守ることが最優先されるため、コードの品質が二の次になる
- 品質の低いコードが蓄積し、バグの発生率が高まる
- バグ対応に時間が取られ、開発スピードがさらに低下する
- 結果として、リファクタリングの時間が確保できず、技術的負債がどんどん積み上がる
このような環境では、「リファクタリングをしたい」「読みやすいコードを書きたい」と思っていても、現実的には難しい場面が多くなります。
こうした問題を解決するために、私たちはどのような行動をとるべきなのでしょうか？
クリーンなコードを書くために必要なこと
私の結論は、「まず正しい書き方の基礎を学ぶことが重要である」ということです。
では、具体的にどのように学べばよいのでしょうか？
私が最もおすすめしたいのは、次の2冊の書籍を読むことです。
📖 リーダブルコード
📖 リファクタリング
どちらも海外の書籍を翻訳したものですが、具体的なコーディング例が豊富に掲載されており、実践的な学びを得ることができます。
「コードをどのように整理すればよいのか」「どのように読みやすい命名をすればよいのか」など、すぐに役立つ知識が詰まっています。
まずはこれらの本を読み、内容を理解し、実際の開発で実践してみてください。
「学ぶ」は「真似る」ことから。
良いコードを知り、それを真似ることで、自身のコーディングスキルを向上させることができるはずです。
おわりに
「読みにくい」「修正しづらい」「なぜこんな実装を…？」
そんなコードに悩まされるたびに、開発の楽しさは薄れ、ただの苦行になってしまいます。
ですが、この戦いに勝つための武器は、すでにあります。
もし、あなたが「クソコード」に振り回される日々に疲れ果てているなら、今こそ、その終わりのない悪循環に終止符を打つときです。
Discussion