過剰分析しているかどうかはどうすればわかりますか?
過去3日間、問題を追跡してきました。私は多くの設計を経験し、約 3 つのクラスを使用して複雑なソリューションに到達しました。同僚と話し合った結果、必要なのは 1 つのメソッドとstruct. 建築宇宙飛行士になるのを避けるにはどうすればよいですか?
6 に答える
5
30 分以内に適切な解決策を思いつくことができない場合は、ほとんどの場合、他の人と話し合うのが最善であることがわかりました。
解決方法がわからない場合でも、多くの場合、より優れた設計またはソリューションのきっかけになります。
だからそれについて誰かに話してください。
于 2009-05-26T14:33:54.780 に答える
2
個人的には、最初にソフトウェアを実際に計画する人に文句を言うことはできません! 私はこれを行いますが、コードに直接ジャンプする方法しか知らないプログラマーをたくさん知っています...そして、そのようなコードを修正する必要があることがよくあります...
そうは言っても、あなたが本当に求めているのは、問題に対するより良い解決策がいつあるのかを知る方法です.
私からあなたへのアドバイスは、繰り返し自問することです: 私は解決策の詳細について考えていますか、それとも本当の問題について考えていますか?
于 2009-05-26T14:38:12.057 に答える
1
アーキテクチャの宇宙飛行士になるのを避ける最善の方法は、すぐに飛び込む習慣を身に付けることです。すぐに飛び込むための最良の方法は、実装が完了して正しい場合に合格するいくつかのテストを作成することです。これにより、最初から「完了」が何を意味するのかに直面することになり、その後のコードの健全性チェックが提供されます。
その後、解決に向かいます。
初めてそこにたどり着くかもしれませんが、「完了」が何を意味するのかをしっかりと頭に入れておくことは、より良い質問をするのに役立ち、事前にいくつかの受け入れテストを行うことは、合理的なものまでスペースを設計します。
于 2009-05-26T15:25:39.510 に答える
0
「理想的な」ソリューションを見つけるために、次の 3 つの手順に従っていることに気づきました。
世界中にすべての時間とリソースがあれば、最善の解決策は何でしょうか。(技術的に、論理的に、パフォーマンス的に、必要に応じていくつかの関連する問題を解決し、見つかったモジュールを書き直すと、より良い結果が得られます...) ここで (過剰) 分析を行って、できるだけ詳しく知るようにしてください。テスト、統計を実行し、概念実証を作成します。
現在の状況とどう違うのか。2 つのソリューションの結果の違いは何ですか。同じまたは類似の結果に到達するためのより高速な方法はありますか。これまたはその変更が目前の問題を解決するのはなぜですか。さらにテストや統計を行い、概念実証を更新してください。
必要な変更を実装する方法を見つけ、必要な変更のみを行い、この変更に不可欠でないものはすべて削除します。問題のないものを変更していないことを確認してください。これをテストし、コード、ロジック、構造への変更を確認します。可能な限りそれらを最小限に抑えます。
これは非常に制限的 (そして多くの作業) に聞こえますが、実際には、データベースにテーブル全体を追加することになる場合もあります。作業の一部 (何かを 100% 確実にするのは大変な作業であるため) は、既存のすべてのコードが、この追加のテーブルに参加してまったく同じように動作し続けることを確認することです。
それに加えて、ほとんどの場合、ここでの作業では、更新前からシステムに残っている「移行データ」に対応する必要があり、更新後にすべて同じように作成および出荷する必要があります。
于 2009-05-26T14:49:37.243 に答える
0
私は最初に簡単で汚いことをするのが好きで、それがうまくいくと、デザインに満足するまでコードを段階的にリファクタリングします。
これもTDDアプローチです。
于 2009-05-26T14:38:49.747 に答える
0
私はかつてこの問題に苦しんでいました。将来の多くの成長とそうでないものを処理できるソリューションを設計します。上記のタイプの懸念につながる適切な抽象化があることを確認しました。
次に、このアプローチを捨てて、すべてを 1 つの大きな汚いクラスにまとめました。おそらく 2 つです。その後、他の誰かに取り組んでもらいたいものに似るまで、それを再分解しました。
于 2009-05-26T14:33:28.587 に答える