コーディング時に解析によって麻痺を克服するにはどうすればよいですか？

新しいプロジェクトを始めるとき、私はしばしばすぐに実装の詳細について考え始めます。「DataBaseHandlerはどこに配置しますか。どのように使用する必要がありますか？それを使用するクラスはいくつかの抽象スーパークラスから拡張する必要があります..？インターフェイスを使用する必要がありますか？を含むクラスで使用する抽象化のレベルリクエストを送信してデータを解析する方法は？」

拡張性と再利用性のためにコーディングしたいので、私は長い間行き詰まってしまいます。しかし、完全に実装する方法について過去の考えを得るのはほとんど不可能だと感じています。

そして、「ネジを締めて、やるだけだ！」と言うと、コードが整理されていないため、抽象化のレベルが混在しているなどの理由で、レンガの壁にすばやくぶつかります。

新しいプロジェクトを立ち上げながら、拡張性の高い論理/モジュール構造をセットアップするためのテクニック/方法は何ですか？

- - EDIT - -

まあ、これはすでに答えを受け入れるのが難しいタイプの質問ですが、いくつかのコンセンサスがあるかどうかを確認して、より多くのフィードバックを取得したいです。TDDは本当にクールに聞こえますが、率直に言って、JUnitなどの使用方法をもっと理解することを意味してきました。同時に、TDDのファンは、TDDに関連する1つの正当な点が特定の問題は、TDDが実際に設計の問題に対処していないように見えることです。確かに、TDDは自分がやりたいことを定義するのに役立ち、徐々にその方法を進めることができますが、ユニットテストをすべて通過できるさまざまな全体的なデザインパターン/構造があります。それだけです：単一のUNITSをテストします。私は少し混乱していると思います...私は知らない。多分、私'

ありがとう！

Test-Driven-Developmentを使用することをお勧めします。特に、Eclipseなどの優れたIDEを使用する場合は慣れる必要がありますが、その利点は素晴らしいです。

基本的にあなたがすることは、コード自体を書く前にコードにテストを書くことです。そのため、使用方法の観点からコードを見る必要があります。つまり、実装するシナリオが増えるにつれて、インターフェイスが進化します。

別の特徴は、非常に小さなチャンクで実装することです（テクニックとプログラミングの経験が豊富になるにつれて大きくなります）。

また、最初にテストを記述してから実装するだけなので、失敗したテストが目の前にあります。あなたがほとんどのプログラマーのようであれば、「このテストを機能させる必要がある」と思うので、クレイジーな分析に夢中になりません。

短いjavaの例：
dbからメッセージを読み書きするプログラムを開発したいとします。

だから私は最初の明確に定義されたアクションから始めます、私はDBが必要です：

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
}

わかりましたので、このテストが失敗するまで、DBを返すようにDbConnector.getDBクラスを実装する必要があることがわかりました。私はそれを行って...

私が次にしたいことを追加するのではなく、DBからメッセージをロードします：

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
  String message = db.fetchMessage(key);
  assertEquals("hello world", message);
}

メッセージを取得するために、DBに別の小さな機能を追加しました。それを実装し、いったん完了したら、次のようなものに到達するまで一度に1つの機能を実行し続けます。

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
  String message = db.fetchMessage(key);
  assertEquals("hello world", message);
  message = "foo bar";
  db.storeMessage(message);
  message = db.fetchMessage();
  assertEquals("foo bar", message);
}

非常に単純な例のように思えるかもしれませんが、これはより複雑なタスクでも同様に機能します。最初は非常に時間がかかることは知っていますが、慣れると実際にははるかに効率的であることがわかります。1つは解析による麻痺を回避し、もう1つは通常はバグが少なく反復回数が少ない、より堅牢なコードを取得します。

これは私に起こるので、継続的なリファクタリングの考え方を受け入れる（そして受け入れる）習慣になりました。おそらく動作する可能性のある最も単純なものを作成し、それをクリーンアップし、整理し、分離し、テストして先に進みます。

だからといって、あまり計画が進んでいないというわけではありませんが、スクラップや私の頭の中にいたずら書きのように、非常にすばやく頻繁に起こります。全体として、私は時々この小さなプロセスをマイクロイテレーションと呼びます。なぜなら、それぞれ5-20分かかり、経験から私が取り組んでいることを完了するのに2-3時間がかかるからです（明らかに私が作っているものによって異なります）。

副次的注意として：私はさまざまな執筆形態（レポート、エッセイ、テクニカルライティング全般）で多くの人々を指導してきましたが、これは作家のブロックを克服するために物事を書かせることと同じ方法です。「ページに思い浮かぶトピックについて何かを曖昧にするだけです。それからそれを理解し、すべてをパラグラフに分けてフローをチェックします。必要に応じて、書き直します。」

動作する可能性のあるいくつかのこと：

• 解決しようとしている中心的な問題を特定します-あなたがしたいことの核心は何ですか？それだけを実装し、最低限のサポートコードを実行して実行します。満足のいく結果が得られたら、繰り返し構築し、各ステップで容赦なくリファクタリングします。
• 他のプログラミングパラダイムが機能するかどうかを確認してください。すべてのメリットにもかかわらず、オブジェクト指向プログラミングはすべての問題に対する答えではなく、すべてのプログラマーの頭脳がそのように働くわけではありません。（純粋な）関数型言語を選択します。いくつかの手続きコードを書きます。ハードウェアレベルに飛び込み、Cまたはアセンブラを実行します。心を揺さぶるいくつかの言語（現在C ++ / Java / C＃/ VB / ...のようなものを使用していると仮定）：Haskell、ML、Lisp（選択可能なさまざまな方言）、Erlang、Prolog、 Smalltalk、Javascript（Javaのように動作させ、代わりにそのクロージャの性質を取り入れようとする場合は手放します）、C、Pascal、awk、そしておそらく12個以上。主な機能は、現在使用しているものとは大きく異なる必要があることです。これは、大きなプロジェクトでやりたいことではありません。
• 根本的に異なる設計方法を使用します。別の角度からデザインをピックアップできるかどうかを確認してください。通常、クラスをレイアウトして設計を開始すると想定しています。変更のためのデータ構造から始めてはどうですか？または、機能を設計する前に文字通り入力フォームを描画して、最初にUIを設計しますか？

多くの設計決定において、「スパイク」を行うことができます。「スパイク」は、使い捨てのプロトタイプにコーディングすることにより、いくつかのアーキテクチャまたは設計オプションを調べることができる、短い時間制限のある研究努力です。たとえば、いくつかのオープンソースライブラリの使用方法や、クラスとインターフェイスを整理する方法を調べることができます。重要なのは、最初の方法が不十分な場合に別のアプローチを試すことができるように短くして、演習で十分な知識を獲得してアーキテクチャの決定を改善したり、コンセプトを証明できるようにすることです。演習自体には、「git 'er done」にあまりにも早くコミットすることなく、「writers block」から抜け出すのに役立つ即時コーディングが含まれます。

その後、Asafがプロジェクトの実装を進めるために言及したTDDまたはBDDアプローチを使用することは有益です。

あなたはそれを必要としないので、最初はあまり考えないでください。

目標と問題を定義し、理解するためにより多くの時間を費やしてください。

「拡張性と再利用性」は、よく書かれたソフトウェアプログラムのライフサイクルの自然な結果です。

私たちは中規模のプロジェクトを見ていると仮定します。
私は、図面ボードに行くことから始めます。これを行う前に、機能要件と非機能要件を準備しておく必要があります。最初にソフトウェアアーキテクチャを考案します。つまり、要件に合ったアーキテクチャパターンを
調べます。アーキテクチャの外観を決定したら、低レベルの設計、つまりすべてのエンティティ、クラス、および機能を検討します。 。ここで、適合するデザインパターンをもう一度試し、識別します。プロセスでは、基本クラスと必要なインターフェイスを理解します。
その後、フレームワークを構築し、これを確認するためにいくつかのクイックテストを実行できます。すべての非機能要件を満たします
その後、@ Asafが示唆したように、テスト駆動開発に進みます。

覚えておいてください、設計とアーキテクチャに十分な時間を費やしているにもかかわらず、必要が生じた場合は常にアーキテクチャを再検討してください。

これは素晴らしい質問だと思うし、誰にとっても何も役に立たない。そのような麻痺は、あなたの分野でますます有能になることの自然な副産物だと思います。そうは言っても、ここで私が支援することはいくつかありますが、問題は解決しません。

• 手付かずのプロジェクトを脇に置き、fuいバージョンで作業します。これは、あなたが自分自身に伝えるバージョンです。コードは見栄えが良くないはずです。実際、大きなリファクタリングと再フォーマットは許可されていません。それは絶対に組織化されておらず、良いコーディングの絆から解放されます。b。動作するだけです。c。私が他のすべての懸念を捨てるとき、私が問題空間について学ぶことは常に私にとって驚きです。私はまた、より賢明な方法で適切な設計に到達するのに役立つことが多い、ちょっとしたヒントになります。

• コンピューターを使用せずに、プロジェクトに参加している時間を十分に確保してください。あなたが本当に達成しようとしていることを概念化し、オブジェクト指向/デザインパターンの狂気を超越する魔法の禅を探してみてください。

あなたの考えに具体的な表現を与えてください：それらを書き留める/タイプする、それらを引き出すなど何でも。これは、必要なときに考えを再検討するのに役立ちます。それはあなたが輪になってから停止します。より明確に考えるのに役立ちます。

自分がどこにも行かず、どこかで何かについて考えているのを見るたびに、私はそれらを入力し、それは私が明確に考えるのに役立ちます。

私は通常、ゼロから始め、可能な限り単純なプロトタイプを作成し、何かを実行します。プロトタイプを使用して、ハッピーパステストケースをリバースエンジニアリングし、テストケースを使用してインターフェイスを駆動し、テストカバレッジを構築するために事前/事後契約を検討します。

問題が完全に理解されるまで、抽象化、最適化、検証について心配する必要はありません。