- 正しさ
- 信頼性
- トレーサビリティ
- サポート性
- ...
これが極端になり、プログラマーが気にするのはコードの美しさだけである場合、リファクタリング症候群に陥る可能性があります。
この症候群には次の症状があります。
- 他のプログラマーのコードを完全に無視します。
- 変数とメソッドの指定に対する執着。
- 単体テストの乱用と再評価。
- あらゆる種類のドキュメント、アーキテクチャ、または分析を完全に無視します。
そして通常、結果：
- 統合エラー。
- 信頼性の欠如。
- パフォーマンスの損失。
リファクタリングシンドロームの主な問題は、コードの美しさに基づいていることであり、これには3つの大きな問題があります。
- 不寛容。 すべてのコードはたわごとです。 これは私のお気に入りの引用の1つであり、次の事実によって証明されています。
- 排除の原則。 すべてのプログラマーは、自分のコードだけが宇宙で唯一の良いコードであると考える傾向があります。
- 陳腐化の原理。 プログラマーとして、あなたは何か新しいことを学んでいるので、古いコードもがらくただと思います。
- 経験の原則。 私が完全に良いと考えるコードを見たことがありません。
- これはそれほど重要ではありません。 コードが良い場合でも、それが正しいことを意味するものではありません。ところで、コードの正確さは美よりも重要なことです。
- 間違った視点。 アプリケーション全体ではなく、コード自体に注目すると、プログラマーはコードの他の重要な部分（アプリケーション）を忘れてしまいます。
このリファクタリングシンドロームは、プログラマーがTDD、リファクタリング、単体テストなどのツールと技術的原則を実際に行う必要があるものと混同するときの最新の人気の傾向に関連しているようです。 これは、新しいツールを持つことは、彼が建設している家よりも重要であると考えているビルダーに匹敵します。
開発ツールや原則はどれも根本的に悪いものではないことを理解することが重要です。 それらを乱用するという事実だけが、リファクタリング症候群に近づきます。
その結果、次のことを覚えておくことが重要です。
- コードが機能しなくても、コードがどれだけ美しいかは関係ありません。
- コードが気に入らないときではなく、必要なときにのみリファクタリングします。 何かに対する同情の欠如は、それを変えるのに十分な理由ではありません。
- 統合に関しては、単体テストは非常に限られています。 実際の手動テストを行ってください!!
- さまざまなツールと技術原則を知っているが、それらを教義として使用しないでください。 それぞれが良い点と悪い点を学び、必要に応じて適用します。
- 優れたプログラマーは、優れたソフトウェアを作り続け、悪いプログラマーは、どの手法を採用しても、悪いソフトウェアを作り続けます。