無臭コードはどの程度悪いのか？-無臭コードの影響を測定する

どのコードの臭いが最も維持しにくいかを測定する科学的実験。臭いコードにどう対処しますか？

かつて私の前任者が教えてくれたように、開発者の第一の責任は悪いコードを書かないことです。あなたが一人軍隊で、すぐに放棄するPerlスクリプトを何行も書いているのでない限り、最も重要なことは、あなたが書くコードが読みやすく理解しやすいものでなければならないということです。メンテナンス可能なコードは、ソフトウェア製品のライフサイクルを通じて、あなたやあなたの同僚がコンピュータの前に座って苦悩したり絶望したりする時間を、多くの場合節約してくれます。

しかし、コードの可読性が低下する原因は必ずしも明確ではありません。これが、コード記述の標準、ガイドライン、コードパターン、プログラミング言語の格言のようなものが存在する理由の1つです。有名なガイドラインの1つに、マーティン・ファウラー（Martin Fowler）著の『リファクタリング（Refactoring）』という本があります1。この本には、一連のコード臭とそれを取り除くためのリファクタリング戦略が書かれています。多くのリファクタリング戦略を学ぶことに加えて、どの戦略の優先順位が高いかを決める必要があります。もちろん、同じように重要であることはありえません！今行っているコード・リファクタリング作業が、長期的にプラスに働くことをどうやって知ることができますか？

問題は、Martin Fowlerのリファクタリングの本には、どのコード臭が重要で、どのコード臭が重要でないかについては書かれておらず、Fowler自身も、人間の直感ほど優れた基準や指標はないと言及していることです。開発者として、リファクタリングが必要かどうかを判断するのは、自分の直感と経験に頼るしかありません。これは悪夢です。何千ものコード臭があるシステムで、どこから手をつければいいのでしょうか？その上、コードへの変更は意図しない副作用をもたらす可能性があります。質の高い自動テストを行ったとしても、コードの変更はしばしばリスキーでコストがかかります。どのコード臭が***破壊的であるかがわかっているのであれば、まずそれを取り除くのが良いでしょう。さらに、きれいなコードを書くために時間を浪費しているのではなく、現在の努力が将来的にプロジェクトに長期的な利益をもたらすことを経営陣に示したいものです。

コード臭に関する事実の収集

2009年、ノルウェーのSimula Instituteは、社内システムを新しいコンテンツ管理システムに移行する必要がありました。このプロジェクトは6人のJava開発者に委託されました。このプロジェクトは、コード臭が保守性に与える影響を詳しく調査する機会と見なされました。

プロジェクトの3ヶ月間、彼らはコード臭を測定するツールを使用し、開発者に毎日インタビューを行い、各開発者のEclipse IDEにロギングツールをインストールしました。ロギング・ツールは、各ファイルの修正にかかった時間だけでなく、コードの検索、閲覧、めくりなどに費やされた時間も記録しました。 プロジェクト期間中は、問題追跡ツールを使って開発者が直面した問題を登録し、問題の原因となっているソースコード・ファイルにさかのぼりました。さらに、すべての開発者にインタビューを行いました。このプロセスで収集されたデータは、コードリポジトリを分析するだけの従来のアプローチをはるかに上回るものでした。以下のような観察がなされました：

観察1：***カテゴリーは実はかなり悪い！

"誰もが知っている "****クラスは悪いものですが、どれくらい悪いのでしょうか？下記をご覧ください：

Y軸はプロジェクトのメンテナンス中にファイルの読み取りと変更に費やされた時間を表し、X軸はファイルのサイズを表します。

なお、***文書の読み取りと修正には、一般的な文書の10倍以上の時間がかかります。このファイルは****クラスです。また、20,000秒はほぼ5時間の作業であることにも注意してください。また、別の大きなファイルの編集にはそれほど時間がかからなかったこともわかります。この大きなファイルにはたくさんのアクセサと修飾子が含まれていますが、ロジックはありません。このため、開発者はあまり時間をかけなかったのでしょう。複雑なロジックを含む大きなファイルは保守性に大きな影響を与えます。

推奨：複雑なロジックを含む大きなファイルは、小さなファイルに分割してください。推奨される閾値は、ファイルサイズを1000行のコードに抑えることです。

観測2：データの塊は、あなたが思っているほど悪くはない ......

データ塊」とは、意味的に関連性のないメソッドや変数の集まりのことです。通常、データ塊が含まれるファイルには、異なる型の変数が含まれ、その後にアクセサと修飾子のセットが続きます。例えば、下図のPersonクラスには、人物に直接関係しない情報が含まれているため、2つのクラスに分けることができます。Simula社の研究者は、コードスプームの存在が、開発者がメンテナンス中に問題を経験する可能性を高めるかどうかを説明する統計モデルを作成しました。その結果、データの塊が含まれる文書は、メンテナンスの問題を引き起こす可能性が低いことがわかりました！

提案：他のコード臭が含まれていない限り、それらのデータの塊は放っておいてください。

観察3：界面分離の原則の順守

ロバート・C・マーティンは、SOLID原則2の一環として、インターフェース分離の原則を紹介しました。

インターフェイス分離の原則とは、ソフトウェア・ライブラリの呼び出し元が、呼び出していないメソッドに依存することを強制されるべきではないというものです。インターフェイス分離の原則は、非常に大きなインターフェイスを、より小さく、より明示的なインターフェイスに分割することで、呼び出し元が知る必要のあるメソッドだけを知ることができるようにするものです。

ソフトウェア工学の研究者3 は、コードの定量化基準を使用していくつかのコード臭を識別する方法を提案しています。いくつかの商用ツールはこれらの定量化基準を実装していますが、独自の検出戦略を考え出し、Java の SonarQube や .NET の NDepend などのツールに実装することもできます。 下図は研究者 Radu Marinescu4 の研究に基づいて Simula が使用する検出戦略を示しています。

このクラスは、クラスの "インターフェイス幅 "が10、クラスの "呼び出し元 "番号が8、"平均インターフェイス使用率 "が0.375です。インターフェース分離の原則。

データ・クラスターに関する分析も同様に、インターフェース分離の原則に違反するファイルを対象としており、あるファイルがインターフェース分離の原則に違反すると、そのファイルが問題を持つ確率が高くなることがわかりました。

下図に示すように、インターフェース分離の原則に違反している文書は、違反していない文書よりも問題が発生する確率が高く、上記の指摘を裏付けています。

推奨: 幅広く、多くの用途を持つインターフェイスをセグメント化することで、メンテナンス時に問題が発生するリスクを減らすことができます。

#p#

観察4：コード臭は集団で発生しやすい

同じ実験で、特定のコード臭は同じファイルに一緒に現れる傾向がありました。下の図を見てわかるように、特定されたコード臭は同じファイルに現れる傾向があります。「臭いをため込む人」は、基本的にシステム機能をすべてため込みたがるファイルです。コンフューザー」は、ファイルに混乱を引き起こすコード臭です。他の2つのグループ、"broad interfaces "と "data containers "は自明です。

推奨：あるファイルにある種のコード臭を発見した場合、そのファイルに他の「臭仲間」が含まれていないかチェックすることをお勧めします。同じファイル内でコード臭が組み合わさっていると、リスクが高まり、保守性が低下します！

ざっと読む

Fowlerが言うように、リファクタリングが必要なものを決めるには、直感、経験、判断に従うことが重要ですが、科学的な調査に基づいた以下のガイドラインは、優先順位を決めるのに役立ちます：

1. ロジックが多すぎる大容量ファイルの分割
2. データ・クラスターを再構築するのではなく
3. そのような広範で多用途なインターフェースを、目的に応じてさまざまなインターフェースに分割します。
4. 特定のコード臭を含むファイルは、同時に多くの「不要な相棒」を持つ傾向があるので、それらを識別するために注意してください！

ハッピー・リファクタリング！

引用

1 リファクタリング：既存コードの設計改善

2 アジャイルソフトウェア開発

3http://...-.///...。

4http://..ro.///.ip

補遺：一般的なコード臭

• 同一または類似のコードが複数の場所に存在する場合。
• 非常に長いメソッド、関数、プロシージャ。
• とても大きなクラスです。
• 関数やプロシージャの引数リストが長いと、コードの可読性と品質が非常に悪くなります。
• あるクラスのメソッドを他のクラスが過度に使用すること。
• クラスは他のクラスの実装の詳細に依存します。
• 機能が少なすぎるクラス。
• :: シンプルなデザインで十分なのに、極端に複雑なデザインパターンを強要すること。
• 特にソフトウェア工学では、あいまいさをなくすために命名規則を遠慮なく使うべきです。
• 変数名がその有用性を反映するものであることが明らかでない限り。
• :: 読みやすさを向上させ、コーディングエラーを避けるために、名前付き定数を使用すべきです。さらに、リテラル値は、可能であれば、リソースファイルやスクリプトに独立して保存することができますし、そうすべきです。