コードが書かれていない数日間、設計上の問題を考えるのは普通ですか？[閉まっている]

ときどき空を見つめたり、アイデアをスケッチしたり、紙の上に擬似コードを書いたりします。それから私はそれをスクラッチしてやり直し、問題の正しい解決策があると思うとコードを書き始めます。

何日もコードを書かずに考えるのは普通ですか？これは、私が問題に近づいているという兆候ですか？IDEで具体的なコードを作成しないことに不安を感じます。

解決しようとしている問題によっては、設計段階に数日ではなく、数年から数か月かかる場合があります（数年ではない場合）。

コードをすぐにバッシュアウトしないようにするには、経験が必要です。アーキテクチャと高レベルの設計について考えるには、もう長くはかからずに何日もかかるはずです-間違いなく、コードを書き始める前に起こるべきことです。

これは一般的に「分析麻痺」と呼ばれます

それは一般的ですが間違っています。ある時点で、さまざまなアイデアをテストして、何が最適かを確認し、徐々に改善する必要があります。

実用的なプログラマー、特に第2章「Tracer Bullets」のセクションを読むことをお勧めします

これは完全に一般的です。ただし、「最初にテスト」またはTDDアプローチを採用する場合、あまり一般的ではなく、アイデアをより適切に策定するのに役立つ場合があります。

習慣は通常、物事に対する試行錯誤のアプローチの結果であり、望ましい結果をもたらすものを継続し、そうでないものを回避します。私たちが好きなことをして、嫌いなことを避けることも同様に作用します。最終的には、家賃を払うために嫌いなことをするからです。

何にあなたを導くのか、そしてあなたの理由に依存します。以下にいくつかを示します。

• 多くの場合、設計変更のためにコードを変更する必要がありました
• 貧弱なソリューションは既にコーディングされているため、貧弱なデザインを変更することはありません。
• コードを作成するよりも、描画して設計する方がいい
• 構文とコーディングの詳細を心配する必要があるため、より良い設計について考えることからあなたをそらします。

うまくいけば、より長く設計すればコードが改善されることを発見できました。振り返って、デザインにどれだけの時間を費やしても問題ないことがわかる場合は、変更することができます。もう1つの考慮事項は、コードを記述した後に問題を発見する頻度と、設計での作業を比較することです。何らかのコードを作成するまで問題を見つけられない場合は、バランスを考慮して、後ではなく早めに何かをコーディングする必要があります。このアプローチは、より新しい技術や非常に複雑な機能の使用に適用できるかもしれません。

あるアプローチが他のアプローチより優れていることを発見したとしても、あるアプローチに固執する規律があるかどうかはわかりません。ホワイトボードに行く必要があると感じることがあります。他のキーボード。

それは非常に一般的であり、物事を処理し理解するためのより良い方法だと感じています。プロジェクトに取り組んでいる間、私は何度も立ち往生しますが、どうすればより良いアプローチができるかを理解するのに1、2日かかります。問題が解決した後でも、1日が経過するのを待ちます。これにより、私はより爽快になり始めます。

それは自然な現象であり、開発者が心の時間とその間の時間を傍受するのは良いことです。

私がプロジェクト管理のコースを受講したとき、インストラクターが計画について私たちに関連していたことの1つは、頭に残っていましたが、軍隊で教えていた経験則は、計画の1/3 。したがって、今から3か月後に完了する必要がある操作がある場合、実行を開始する前に計画に1か月を費やすことを考慮してください。

私の見解では、3つのアプローチがあり、それぞれ特定のコーディング状況に適しています

1. 以前に同様の問題を見たことがあるので、適用するパターンについてかなり良い考えがあり、ソリューションがどのように振る舞い応答するべきかが明確になっています。

   => BDD / TDDを使用し、目的のソリューションから始めてコードを作成します。（まあ、時々私はチートしてコードを少し書いてからテストを書く-一種のネストされた2-> 1.アプローチ）。

2. 適用するパターンについては良いアイデアを持っていますが、ソリューションがどのように見えるかはわかりません。

   =>どんな種類の興味深いものが飛び出すかを見るためのプロトタイプ。どの興味深いものが望まれているのかを理解したら、1に進みます。

3. どのパターンを適用すべきかわかりません。

   =>問題と、問題にアプローチするさまざまな方法がコードにどのように影響するかを考えてください。その演習の結果に応じて、2）または1）に移動します。

言い換えれば、答えはエンジニアのお気に入りです。

基準を満たしていない設計に基づいて簡単なプロトタイプを作成するよりも、考えて設計するのに1か月を費やす方が良いでしょう。特にあなたがチームにいる場合; コードに応じて他の人が開始すると、別のAPIを使用してより良い設計を実装することははるかに困難になります。

原則として、問題/解決策を考えるのに時間をかけることは良い考えであるという他の答えに同意します。ただし、立ち往生しているように感じる場合は、計画プロセスをより一貫性のあるものにする方法についていくつかの推奨事項があります。

• 設計成果物を作成します。では、コードを記述しないとどうなりますか？たぶんあなたは自分の考えの日記を書き留めるだけかもしれません。または、一般的なソリューションのスケッチ。または、時間の経過とともに改善される問題の非常に優れた要約ですらあります。アイデアを検討し、それらを受け入れ/拒否するときは、そのテーマに関する推論のログを保管してください。このようにして、一日の終わりに、あなたはまだあなたの労働の証拠として現実世界の成果物を指すことができます。

• 人に話します！アイデアを話し合うために生きて呼吸する人間がいるのに勝るものはありません。立ち往生していると思われる場合は、誰かと話し合ってください。誰かをつかむ-誰も！-そして問題を彼らに説明してください。問題の解決方法に関する考えをスケッチします。せせらぎをしながら10分間息を吸って吐き出し、瞬きするだけでも、問題を説明する過程で新しい洞察を発見できる可能性があります。

サッチェル・ペイジが言ったように、「時々座って考え、時々座っているだけです。」

彼が得ていたのは、あなたの問題を別の方法で考えるようになるかもしれないので、あなたの心をクリアすることが時々良いことだと思います。そのため、コードを無視していなければ、他の方法では回避できたかもしれない解決策やアイデアを思いつくかもしれません。ですから、はい、それは正常であり、コーディングに飛び付かないことをお勧めします。

このプロセスを自分で行うには2つの方法があります。テキストファイルとプロジェクトに関連する図面があるフォルダーを作成します。そこでアイデアを書き留め、考えられるすべてのプロセスをできる限り保存します。また、アルゴリズムからCSSレイアウトまでの簡単なアイデアをすばやくテストできるスクラッチパッドプロジェクトを作成します。

プログラム=アルゴリズム+データ構造

私見、設計（問題解決）プロセスは完全にルールです。実装（技術的な問題）の詳細は自然に続き、解決します。

これが私の考えです。

1. 最初から始める最初に、あなたが望むものの大まかなアイデアが必要です。いくつかの要件のリストを取得するか、作成してください。ここで問題を解決するには少し時間がかかります。少なくとも自分が望む自信のあるピースを手に入れたら、そのピースのインターフェイスの大部分を知ってから、コーディングを開始します。

2. 既存のコードに関する問題の修正まず、問題を追跡します。これには、実際のコードを作成しない時間が必要になる場合があります（一部のデバッグコードが作成される場合がありますが、通常は保持されません）。問題が見つかったら、複雑さに応じて、コードを書き始めて問題を修正します。バグがわかったら、ほとんど考える必要はありません。問題が主要な設計上の欠陥であることが判明した場合、次のセクションを参照してください。

3. 設計変更/主要な機能これは、ほとんどの場合、最も考慮が必要なものです。構造を保存すること、後方互換性などを考慮する必要があります。最善の変更を検討することで時間を大幅に節約できますが、通常、私にとっては数日以内です。

4. シンプルな機能の追加大幅な設計変更が必要ない場合は、試行錯誤を行って機能にコードを追加します。これは一般に膨大な時間を必要としません。

私はこれに関するコンセンサスに同意しません。私のシステムをどのように機能させたいかについて、ナプキンに書かれた漠然としたアイディアさえ得たら、すぐに何かのプロトタイプを作り始めたいと思います。物事を非常に正確な方法で指定しない限り、問題を引き起こす可能性のある細かい部分をすべて考えることはほとんど不可能です。私がデザインについて人々と話し合っているだけなら、もっと複雑な問題のいくつかを手で振り回すのは簡単すぎます。このように指定すると、他の表現方法ではなく、ソースコードに直接含まれる可能性があります。他の表現方法は、正確で形式的ですが、コンパイルおよび実行できません。

それは、「通常」の意味に依存します。私自身について言えば、コードは素晴らしい学習ツールだと思います。そのため、複雑な問題に直面したときは、紙の上でスケッチを行いますが、テスト駆動型コーディングも行います。コードは、ホワイトボードでは言い表せない、またはその逆であると考えていることを教えてくれます。その結果、洞察力が得られるか、ドメインの専門家にさらに質問をする必要があるかもしれません。

したがって、本当のアドバイスは、「問題定義に近づくために必要なすべての学習ツールを使用する」だけでなく、「これらは学習ツールであることを忘れないで、それらに恋をしないこと」です。

RADとアジャイルプログラミングのこの時代では、システムの主要部分を特定できるようになったらすぐに開発を開始する必要があります。詳細が明らかになります。ソフトウェアが大きくなっているので、すべての詳細に時期尚早に集中しても、どこにも行けません。