仕様が正しく指定されていないことが判明した1つのマイナーな仕様変更のために、作業が破棄されました。プロジェクトの開始時にそれが行われていれば、そもそもその作業のほとんどは必要なかったでしょう。
これらのことが起こらないようにするためのいくつかの良いヒント/設計原則は何ですか？
または、機能要求を実装したり、実装の途中で設計変更を行ったりするために必要なコードの再作業の量を減らすには？
9 に答える
6
モジュール化する。うまく機能するコードの小さなブロックを作成します。しかし、それはほんの始まりに過ぎません。それは通常、コードに寄与する要因の大きな組み合わせであるため、完全なやり直しが必要です。非常に不安定な要件、貧弱な設計、コードの所有権の欠如など、すべてがリストに載っています。
他の人が提起したものに加えて：コミュニケーション。
あなたと顧客、あなたと経営陣、あなたと他の開発者、あなたとあなたのQA部門の間のコミュニケーション、すべての人の間のコミュニケーションが重要です。経営陣が合理的な時間枠を理解していることを確認し、あなたと顧客の両方があなたの建物が何であるかを正確に理解していることを確認してください。
于 2009-06-02T00:39:12.513 に答える
4
時間をかけて、製品を構築する顧客とのコミュニケーションを開いてください。マイルストーンを作成し、各マイルストーンでプロジェクトを顧客に表示する時間を設定します。マイルストーンを表示したときに顧客が完全に失望した場合でも、持っているものをスクラッチして、最後のマイルストーンからやり直すことができます。これには、Csunwoldが述べたように、互いに独立して機能するブロックに作業を組み込む必要もあります。
ポイント...
- オープンなコミュニケーションを維持する
- 製品の進歩にオープンで正直であること
- お客様のビジネスニーズや製品変更の仕様については、日々変更していきます。
于 2009-06-02T00:45:12.020 に答える
2
ソフトウェア要件は変化し、クライアントとのより頻繁なやり取りを除いて、それについてできることはあまりありません。
ただし、変更に直面してもより堅牢なコードを作成することはできます。誰も必要としなくなった要件を満たすコードを捨てる必要はありませんが、そのような変更の影響を減らすことができます。
たとえば、これが当てはまる場合は常に、クラス（または言語の同等のもの）ではなくインターフェイスを使用し、絶対に必要であることが確実でない限り、インターフェイスに操作を追加しないようにします。そのようにプログラムを構築することにより、特定の実装の知識に依存する可能性が低くなり、不要なものを実装する可能性が低くなります。
このアプローチのもう1つの利点は、ある実装を別の実装に簡単に交換できることです。たとえば、（効率的に）最も馬鹿げたものを書くことで利益が得られることもありますが、プロトタイプの実装を記述してテストするのが最も速く、プロトタイプが製品とパフォーマンスの基礎である場合にのみ、最終的にはよりスマートなものに置き換えます。重要です。これは、時期尚早の最適化を回避し、それによって物を捨てるのに非常に効果的な方法であることがわかりました。
于 2009-06-02T01:02:12.843 に答える
2
小さく繰り返す
頻繁に繰り返す
反復間のテスト
クライアントが入力を提供できるように、できるだけ早く簡単に機能する製品を入手してください。
基本的に、ものが捨てられると想定しているので、適切にコーディングし、捨てるのに多くの時間がかかるようなものに十分に踏み込んではいけません。
于 2009-06-02T01:13:04.630 に答える
2
言われているように、モジュール性が答えです。しかし、実際に使用するのは難しい答えになる可能性があります。私はに焦点を当てることをお勧めします：
- 事前定義されたものをうまく実行する小さなライブラリ
- モジュール間の最小限の依存関係
最初にインターフェイスを作成することは、これらの両方を実現するための良い方法です（依存関係に使用されるインターフェイスを使用）。次に、コードを作成する前に、インターフェイスに対してテストを作成すると、モジュール式ではない設計上の選択が強調されることがよくあります。
アプリがUIを多用するかどうかはわかりません。モジュール化が難しくなる可能性があります。それでも通常は努力する価値がありますが、そうでない場合は、やがて破棄され、氷山の原則に従うと想定します。作業の90％はUIに関連付けられていないため、モジュール化を維持するのが簡単です。
最後に、ヒントが満載のアンドリュー・ハントとデイブ・トーマスによる「実用的なプログラマー」をお勧めします。私の個人的なお気に入りはDRYです-「自分を繰り返さないでください」-同じことを2回言うコードは匂いがします。
于 2009-06-02T02:33:46.980 に答える
1
時々、書き直しが最良の解決策です！
カメラ用のソフトウェアを作成している場合は、次のバージョンでもビデオ、ステレオビデオ、または3Dレーザースキャンを実行し、これらすべての機能のすべてのフックを含めることができると想定できます。または、このような用途の広い拡張可能な宇宙飛行士アーキテクチャを作成することもできます。ジェットエンジンを含む次のカメラに対処しますが、お金、リソース、パフォーマンスに多大なコストがかかるため、それを行わない方がよいかもしれません。
新しい役割の新しい機能を完全に書き直すことは、必ずしも悪い考えではありません。
于 2009-06-02T02:58:50.097 に答える
1
G'day、
ここで他の答えを見ると、誰もがあなたの次のプロジェクトのために何をすべきかについて言及していることに気づきました。
しかし、欠けているように見えることの1つは、仕様の理由を見つけるためにウォッシュアップを行うことです。同期していませんでした。顧客が必要とする実際の要件で。
これを行わないと、次のプロジェクトを実装するためにどのようなアプローチをとっても、実際の要件と仕様の間にまだ不一致があるのではないかと心配しています。次のプロジェクトでは、もう一度同じ状況になります。
それは、コミュニケーションの悪さや顧客の要求が這うような単純なものかもしれません。
しかし、少なくとも原因がわかっていて、それが再び発生する可能性を最小限に抑えるために努力することができれば。
他の答えが言っていることをノックしないでください、そしてそこにいくつかの素晴らしいものがあります、しかしあなたがそれを繰り返すことを非難されないように起こったことから学んでください。
HTH
乾杯、
于 2009-06-02T02:44:45.880 に答える
0
csunwoldが言ったように、コードをモジュール化することは非常に重要です。1つのピースがエラーになりやすい場合でも、システムの他の部分を台無しにしないように記述してください。このようにして、1つのバグのあるセクションをデバッグしながら、残りのセクションに安全に依存することができます。
これを超えて、ドキュメントが重要です。コードにきちんと明確に注釈が付けられている場合、将来的にコードを作り直すことは、あなたやデバッグをしている人にとっては非常に簡単になります。
ソース管理を使用することも役立ちます。コードの一部が正しく機能しない場合は、常に過去の堅牢な反復に戻る機会があります。
于 2009-06-02T00:49:05.613 に答える
0
あなたの例には直接当てはまりませんが、コードを書くときは、ソフトウェアが将来進化するのを見ることができる方法に注意を払うようにしています。
基本的に私はソフトウェアがどこに行くのかを予測しようとしますが、批判的には、私が想像できることのいずれかを実装したいという誘惑に抵抗します。私が求めているのは、APIとインターフェースが、これらの機能をまだ実装せずに可能な未来をサポートできるようにすることです。これらの「可能なシナリオ」が、より優れた、より将来性のあるインターフェースを思いつくのに役立つことを願っています。
もちろん、常に機能するとは限りません。
于 2009-06-02T00:52:45.670 に答える