時々、ストーリーのあるプロジェクトを開いて、このプロジェクトのストーリーが長いことを理解します...はい、そして著者は変わっており、彼らはほとんど経験がなかったことは明らかです。
これは何で表現されていますか？ -システムのすべての部分が絡み合っているため、1つのピースを引き裂いて他の場所で使用することは不可能です。 その結果、このようなプロジェクトは、もちろん、QAグループの受け入れテスト以外の単体テストではカバーできません。 これは、他の変更が他の部分を壊さないという自信を失うため、時間が経つにつれて、洗練のコストが増加することを意味します。
プロジェクトの質の低さの別の症状は、1つのクラスが同時に多くの役割を実行するという事実、つまり、このようなマルチステーションワゴンです。 これは、多くの場合、開発者が単に怠けすぎて新しいクラス/インターフェイスを記述できず、通信を再構築してシステムに入力するためです。 「別のメソッドをここに追加しても、悪いことは何も起こらないからです」と彼は考えます。 しかし、1つのメソッドの後、2番目と3番目が表示されます。 開発者が上級の場合、「技術的義務-すべてをリファクタリングし、すべてに分割する必要がある」というタスクを書き留めますが、多くの場合、問題が存在することに気付かないこともあります。 これは通常、良い適切な経験を持つ専門家がいない若いチームでは一般的です。
しかし、経験のある専門家がいるのに、プロジェクトはまだ混乱した状態にある可能性はありますか？ はい、それは起こります。 原則として、1人の開発者が実施するプロジェクトで、誰も彼を正しい道に設定しません。 そして、彼は成長し、すでに「私はここで長い間働いています」、「ここで働いて、私と一緒に働いてから話す」という評判を持っています。 彼には、これは複雑すぎて混乱しているようです。
専門家が「高速」で異常な機能を備えたオブジェクトを展開する状況を見ることができます。 ただし、プロは、 今すぐに問題をすばやく解決するか、レイアウトを作成することを確信しており、 明日はリファクタリングを実行する必要があります。 しかし、このアプローチは、非常に短い期間の高速で短いプロジェクトでのみ正当化されます。 技術的負債には独自の金利があり、毎週増加します。
どのデザインが良いのか、どのデザインが悪いのかを理解する方法 簡単な基準をお勧めします：
クラス/システムオブジェクトごとに、質問への回答を記述します。
- クラスは何をすべきですか？ 彼の責任範囲は何ですか？
- クラスは何をすべきではありませんか？ クラスが絶対に入らない隣接エリア。
これらの質問に対する回答は、最も重要な質問に回答することで確認する必要がある関連事実のシステムを形成します。
なぜ（この機能/アクション/機会）がこのクラスによって提供されるべきだと思いますか？
以前に記録された事実と矛盾しない論理的で一貫した証拠を見つけた場合、プロジェクトの設計は良好です。 疑わしい場合は、何かが間違っているため、再設計を検討する必要があります。
これは、もちろん、設計が良好であることが保証されるという事実から保護するものではありませんが、思考を生じさせます。
これらの問題に加えて、初期段階で間違った決定を「キャッチ」できるようにするいくつかの指標をさらに適用できます。
クラスには複数の役割があります。 「クラスは何をすべきか」という質問に答えて、可能性のリストを始めたいと思います。 そして、あなたは最も重要なことに集中することはできません。 これは、いくつかのクラスに分割することを考える必要があることを意味します。
クラスが何をするかを1つの短い文で表現することはできません。 これは、彼の責任範囲があいまいであり、このクラスが必要な理由が理解できないことを意味します。 この指標は、将来これが「ゴミの山」になる可能性があることを示しています。
いくつかの保護されたデータまたはメソッドを引き出すことが切望されています。 クラスの役割が変化していることを示し、データのアグリゲーターになります。 クラスの目的とその制限を再確認することは理にかなっています。
このような単純な論理ツールを使用すると、アーキテクチャの安定性をすばやくチェックして、 ガタガタにならないようにすることができます。
質問：同僚、設計の安定性をテストするためにどのような方法を使用していますか？