【結論】
・コードの臭いとは、コードの不吉な兆候として表れるサインを示したものです
・可読性や拡張性を高める為のリファクタリングを行う際に、コードの臭いを嗅ぎ分ける能力が重要になる
・コードの臭いに鋭くなるには、プログラミングの原則を理解し、様々な設計上の問題について把握しておく必要がある
【目次】
【本題】
コードの臭いとは
エンジニア間でのコミュニケーションにおいて、独特の表現が用いられるケースが多々ありますが、その中の一つに「コードの臭い」と呼ばれるものがあります。
コードの臭いとは、コードの不吉な兆候として表れるサインを示したものです。
不吉な兆候とは、理解しづらい、拡張性に乏しい、バグが発生しそうなど、深刻な問題に繋がる可能性がある事を指します。
このコードの臭いに対する感度の高さは、エンジニアとしての能力の高さと直結します。
嗅覚が求められる理由
エンジニアにコードの臭いを嗅ぎ分ける能力が求められる理由は、ソフトウェア開発において欠かせないリファクタリングを行う上で、必要な能力だからです。
原則としてソフトウェアは、一度作って終わりではなく、何度も機能追加や修正などを繰り返します。
そうする中で、コードは徐々に汚れていき、デバックがしづらくなったり、既存のコードを再利用しづらくなったりなどすることで、開発コストが増加していきます。
その問題を解消する為に行われるのが、リファクタリングです。
リファクタリングとは、外部から見たコードの動きは変えず、コードの構造だけを改善することです。
これにより拡張性や保守性を高めることが出来ます。
しかし、リファクタリングを行うには、どのコードに手を加えるべきかを適切に判断出来なければなりません。
ソフトウェアが正常に動作していれば、ソフトウェア自体が、改善が必要な箇所を知らせてくれることはありません。
なので、エンジニアが自ら問題箇所を察知するスキルを身につける必要があるのです。
臭いの傾向
コードの臭いには、いくつかの傾向が存在します。
以下がその代表例です。
DRYで無い・・・同じようなコードをコピペで量産して、修正が面倒。
長過ぎる・・・関数（メソッド）が長過ぎて、見通しが悪い。
大き過ぎる・・・モジュールが大き過ぎて、責務が曖昧。
多過ぎる・・・モジュールが多過ぎて、処理の流れが追いづらい。
名前の不一致・・・名前と実際の動きが乖離していて、誤解を招く。
コードの臭いを嗅ぎ分ける方法
コードの臭いを嗅ぎ分ける為には、普遍的なプログラミングの原則について理解を深めることが重要だと考えられる。
例えば、有名なプログラミングの原則にDRYやKISSなどがあります。
また、設計原則であれば、SOLIDやデザインパターンなども有名です。
それと、利用しているフレームワークでよくある設計上の問題を、事前にキャッチアップしておくことも大事です。
その他、OSSのコードリーディングなどで、細かいベストプラクティスを収集するのも効果的だと考えられます。
これらの設計原則が、全てで最適解であるとは限りませんが、事前に知っておくことで、判断の軸が定まり、より効果的な手法を採用しやすくなると考えています。
参考情報
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
《今日の学習進捗（3年以内に10000時間に向けて）》
モンキーテスト中に、別機能のバグがたまたま見つかった。
DBに設定項目を持たせて、それを参照する機能だが、設定項目を追加する際に、DBの更新が漏れていた事が原因だった。
このDBを参照する方法は、作業漏れの危険性があるのは勿論、本番へデプロイする際に作業が多少増えるという運用上の問題を抱えている。
かなり広範囲に影響する箇所の為の、直ぐに手を付けるべきでは無いと思うが、ゆくゆくはモデルに寄せるなどして対策を講じたい。
また、バグの発生を恐れて、本番へのマージを後回しにしてしまい、かなり溜まってきてからデプロイしているが、一回のデプロイでの変更箇所が増えるとチェックの精度が落ちるので、直ぐに本番へマージさせた方が良いのかもしれないと考えている。
学習開始からの期間 ：238日
今日までの合計時間：2285h
一日あたりの平均学習時間：9.7h
今日までに到達すべき目標時間：2174h
目標との解離：111h
「10,000時間」まで、
残り・・・「7715時間！」