要件が頻繁に変更され、時間内にコードを提供したい場合、スパゲッティへの移行を克服するために使用される最適なソリューションまたは方法論は何ですか?
10 に答える
18
スパゲッティ コードの定義は何ですか? 私にとって、スパゲッティ コードは長すぎ、構造化されておらず、無秩序なメソッド/関数です。これは、要件の変更によるものではなく、開発者の怠惰によるものです。状況が変わったためにメソッドを書き直す必要がある場合は、オーバーヘッドをあまりかけずに直接クリーンアップすることもできます。
オブジェクト構造の設計が悪いというのであれば、その通りです。要件の変化が速すぎると、クラスが意図したとおりに機能しなくなったり、オブジェクト階層が不適切になったりすることになります。
これを回避するためのヒントがいくつかあります。
最初から過剰に設計しないでください。変更が難しくならないように、メソッド、クラス、およびクラス階層をできるだけ単純に保つようにしてください。
要件が変更された後、すぐに実装を開始するのではなく、一歩下がって、新しい機能が収まる前にコード構造を変更する必要があるかどうかを確認してください。
変更には時間がかかることをクライアントに伝えます。要件を変更するとコードの構造も変更されることを彼らが知っていることを知っていれば、コードを既存の構造に押し込むプレッシャーが軽減されます。
コーディング中は常にリファクタリングしてください。私の経験では、冗長なコードをいくつかの場所から単一のメソッドまたはクラスに移動するなどの小さなリファクタリングが、コードをクリーンに保つのに最も効果的です。常にコードの臭いに注意し、作業を容易にするためにできるだけ早くそれらを削除してください。これにはある程度の経験が必要ですが、今こそトレーニングを開始するのに適した時期です:-)
krosenvold が言ったように、コードにテスト ケースを追加して、大きな変更に対する恐れを取り除いて安全にプレイしてください。私自身、大規模なレガシー システムに取り組んできたので、この恐怖と、セーフティ ネットなしで作業することがどのような感じかを知っています。最初にセーフティネットに取り掛かると、必要な変更を加える冒険が少なくなります。
于 2009-01-27T07:10:21.127 に答える
4
キーポイントの 1 つは、簡単に変更できるコードを記述することだと思います。これは通常、抽象的ではなく具体的なものを優先します。また、コードを通じて非常に大きな柱を構築する傾向がある設計パターンもいくつかあります。そのような柱は、実際に変更する必要があるコードの記念碑的な中心部分を変更することを恐れているため、間違った場所で変更を行う傾向があります。
テスト カバレッジは、大胆なリファクタリングを可能にする上で非常に役立ちます。クレイジーなテスト プレーン パイロットと正気なテスト プレーン パイロットの違いを生むのは、パラシュートです。
于 2009-01-27T07:00:11.317 に答える
2
機能の追加や削除など、プロジェクトの要件に対する頻繁な変更は、必ずしもスパゲッティ コードにつながるとは限りませんが、モジュラー ソフトウェアを作成していない場合は、おそらくスパゲッティ コードになる可能性があります(モジュラー プログラミングを参照)。努力すべきことには、次のようなものがあります。
- 各モジュール (関数、クラス、ライブラリ、または完全なアプリケーションのいずれであっても) には、明確に定義された目的があります。
- 各モジュールは、定義された目的を果たすのに必要なサイズより大きくないことが理想的です。
- モジュールは疎結合です。つまり、ソフトウェアを壊すことなく他のモジュールに置き換えることができます。
- モジュールを個別にテストして、エラーなく目的を果たしていることを確認できます。
- モジュールは、問題のドメインを他のプログラマーにとって直感的に理解できるように編成されています。
よく構成されたモジュール (関数、クラス、ライブラリ、完全なアプリケーションなど) が疎結合されながら連携する場合、要件の変更に対処する方法は、新しいモジュールを作成し、既存のモジュールを拡張し、接続することです。モジュールを新しい方法で。
そもそもこれらの優れたソフトウェア モジュールを使用する状況にどのように到達するかについては、リファクタリングが重要です。単体テストや開発方法論 (スクラムなど) などの他の手法も役立ちますが、リファクタリングは必需品であり、多くのビジネス環境では十分な時間が確保されていません。
疎結合コードの作成に関する適切なアドバイスについては、依存性注入に関する調査を行ってください。
于 2009-01-27T07:38:40.710 に答える
2
適切なテスト カバレッジは、頻繁な変更に対する最善の防御策です。
于 2009-01-27T07:00:30.957 に答える
2
- 可能であれば変更を予測し、可能であれば要件を一般化する
- さらに重要なことは、変更間の時間を予測することです
- 変更の間の時間内に完了することができるように、作業/機能/反復をチャンクします
- 出来上がり！あなたは今、その場でアジャイルを行っており、絶え間ない変化は普通のことのようです 8-P
- アスピリンを飲んで、上司に泣き言を言って、#1 に戻ります ;-)
于 2009-01-27T07:22:17.967 に答える
0
1つのアドバイスを残している場合：リファクタリング、リファクタリング、リファクタリング！頻繁！
他のすべては、リファクタリングを簡単にするための詳細です。
于 2009-01-27T11:25:37.007 に答える
0
スコープ クリープ/不適切な要件分析 (変化し続ける):
あらゆる品質 (コードまたはその他) を保証するために与えることができる最善のアドバイスはペストのように避けてください。開発プロジェクトをどれだけうまく計画しようとしても、常に (すべての面で) 悪影響を及ぼします。
最善の解決策は、マイルストーンを設定し、要件を変更し続ける人にこのリンクを表示するタイミングを知ることです。
既成概念にとらわれずに考え、コードをできるだけ簡単に変更できるようにすることで、非常に人間的になることができますが、プロジェクトの品質時間にどのように影響するかを理解せずにすべての機能に「はい」と言うと、恐ろしく失敗します. -スコープ ピラミッド。
于 2009-01-27T08:14:56.673 に答える
0
頻繁に変化する要件は、対処するためにアジャイル手法が開発された問題です。それらは、多くの場合、非常に正当な理由で、要件が変化するという問題を認識して、少なくとも部分的に作成されました。
まだ実装していない要件が変更された場合、事前の設計に多くの労力を投資せず、小さな反復、絶え間ないテスト、およびリファクタリングによって設計の進化を管理すれば、影響は最小限に抑えられるはずです。
すでに実装されている要件が変更され、完了日を変更できない場合は、次の 3 つの選択肢があります。失われた時間を取り戻すために長時間働くか、要件を削除して (スコープを縮小して) 余分な作業の費用を支払うか、品質を下げるかです。製品の（「スパゲッティ」オプションである可能性があります）。
于 2009-01-27T08:51:43.463 に答える
0
頻繁な要件変更へのケータリングは、次の目的で行われます。
- オブジェクト指向設計（ビジネスドメインを抽象化し、管理可能な目的指向の概念に分割する）
- 設計パターン (確立されたコーディング ソリューションを再利用)
- MVCベースの開発（データ分離、ビジネスロジックとView/Presentation）
- アーキテクチャ フレームワーク ベースの開発 (プロジェクト固有の設計と開発をコミットする前に、まずアーキテクチャ フレームワークを設計します)
したがって、スパゲッティを避けたい場合は、上記の概念を学び、適用してください。
于 2009-01-27T07:02:23.077 に答える
0
どのような要件でも、可能な限り変更できるようにコードを設計してください。これは、不変部分を可変部分から分離することによって行うことができます。これにより、開発までに時間がかかりません。ほとんどの場合、スパゲッティ コードは要件の変更によって出現しますが、設計とプログラミングはそれに耐えられるはずです。
http://www.dreamsongs.org/Files/DesignBeyondHumanAbilitiesSimp.pdfが参考になります。
于 2009-01-27T07:10:36.477 に答える