非常に頻繁に、最良の設計決定を選択するときに立ち往生しています。関数定義、制御フロー、変数名などの小さな詳細であっても、選択の利点とトレードオフを熟考するのに異常に長い時間を費やします。
これらの重要でない詳細に時間を費やすことで、多くの効率を失っているように感じます。私の現在のデザインがうまくいかない場合、これらのことを変更できることを心の奥で知っていますが、1つの選択肢をしっかりと決定するのに苦労しています。
この問題に対処するにはどうすればよいですか？
回答:
2つの簡単なルール：
これらの各作業を開始すると、後で変化に対応する能力を損なうことなく、今すぐ簡単な決定を下せるという自信が得られます。
将来の校正とは、コードの変更が必要になる可能性のあるあらゆる方法を予測しようとするのではなく、コードを簡単に変更できるようにすることです。
通常、そのように感じるとき、それは私が試してみる必要があることを意味します：
問題に構文と小さな断片が関係している場合：
自分が無作法だと考えるのはとても簡単です。たとえなんとかして、プロジェクトを完了する前に簡単に変更できる最高のソリューションを今すぐ思いついたとしても、それから何をしますか？
適切なソリューションを選択して実行する方が、最良のソリューションが何であるかをじっくりと考えるよりも優れています。最善の解決策は、とらえどころのないものであり、さらに悪いことに主観的なものです。要件が少しでも変更された場合、そのソリューションはその時点で最良ではなかったため、破棄したソリューションよりも悪化することがあります。
私も分析の麻痺を避けることを学んでいるので、私たちへの称賛=）これは私たちが「最良の設計」をしたいためによく起こります。実際には、「最高」は見る人の目にあります。分析の麻痺を避けるための私の公式は、十分に良い設計原則を適用することです。どうやってやるの？私は時間制約、スケジュールなどの変数を持ち、品質を損なうことなく仕事を完了することができる最も簡単な設計（これは最も簡単なことではありません）を自問しますが、同時に、それがテスト可能であり、変更のために閉じられた拡張用のオープン（OCP）デザインも。テスト可能なOCPとはどういう意味ですか？まあ、私がベストだと思ったものを探す代わりに、私は物事が悪くなっているときに教えてくれ、後でリファクタリングと改善ができるだけのコードを実行しようとするデザインを考えました。また、変わらないコードで変更されるコードを分離するようにしてください。リファクタリングは簡単になります。これは、変更する必要のないコードが、将来のあなたや他の誰かから安全であるためです。
あなたの腸の感覚にオプションの1つを決定させるのはどうですか？それはかなり速く進み、amboxが提案したタイムボクシングとうまく結合するはずです。オプションが既に確立されている場合は1分間、最初に定義する必要がある場合は2分間の制限を試すことができます。または、適切と思われるもの（事前定義済み）。腸の本能に耳を傾けることを学ぶとき、あなたの直感的な選択は練習でより速く、より良くなります。
完全ではない選択の可能性についての心配に悩まされている場合、以下に対処するためのいくつかの考えがあります。
幸運を！:)
プロトタイプを作成します。プロトタイプは捨てられるように作られているので、どの関数、変数名、または大規模なアーキテクチャを使用しても問題ありません。それが機能することを証明するために構築するだけです。
あなたがそれを作成し、それを捨てたら、私はあなたがそれらの決定をするのがより簡単な時間を持っているに違いないと思います。
私もこの問題に苦しんでいます。私が言うことは、あなたには十分な完了インセンティブがないということです。
たとえば、レンダリングコードを書いているときに、完了の大きなインセンティブがありました。それを使って、システムの動作を確認し、クワッドをテクスチャリングするのがどれほど素晴らしいかを考えて、または頂点を変換します。しかし、今、リファクタリングしているので（あなたが知りたい場合は4を試してください）、それは多くの仕事であり、私が終わっても、同じ古いクワッドを見るだけで苦しんでいます。そして、私は本当に再びリファクタリングする必要はありませんし、同じ古いクワッドを何度も何度も見るのはうんざりです。それはもはや私にとって報酬ではありません。
それをコンポーネントに分解し、それが機能していることを示すコンソールI / Oがある場合でも、それらを完了したことに対して自分に報酬を与える必要があります。
私はあなたの質問を読んで、他のポスターに沿って物事を考えていました。あなたはこの仕事には向いていません。自分に時間制限を与えます。ちょっと他のことをしてください。熟考した後、答えが本当に役立つかどうかわかりません
このような精神的な問題の問題は、解決するのが簡単ではなく、あなたの一部であり、明らかにあなたが仕事を気にしている（おそらく多すぎる）、あなた自身に同意する自信を持っていないことです自分が最初の選択だと考えるのは経験が浅かったので、完全に正しいことを強調しすぎていました。なぜこのような些細さを心配するのでしょうか？！
今、私は同様の問題を抱えていますが、コードではあまりありません..通常は夕食に何をすべきか..ピザやカレー。 、しかし、あなたはより多くのカレーを得るが、しかし...など。:)
だから私は考えました-コーディングで同様の問題を抱えていないのはなぜですか？関数定義が必要な場合は、簡単です。これまでにコーディングした他のすべての関数定義と同じようになります。制御フローが必要な場合は、まずforループまたはwhileループが必要かどうかを判断してから、これらのいずれかが必要なときに前回使用したのと同じ古いコードを作成します。同じことがすべてに当てはまります。キューが必要ですか？確かに-「標準」キューコード（最後に取り組んだプロジェクト、またはこれらのいずれかを使用して覚えているプロジェクトから取得したもの）をカットアンドペーストできます。最終結果...私は新しいものだけを気にします、そして正直に言うと、それは喜びです。
したがって、私のアドバイスは、コードスニペットのライブラリの構築を開始することです-私はそれらを自分に電子メールで送信し、フォルダに入れていましたが、あなたが作業するものは何でも最高です-そして、あなたは毎回何をすべきかを知るようになります。常に、作成した古いコードに移動して、次の問題に備えて問題を回避します。あなたははるかに速い開発者になります（真剣に、これはプログラマの生産性を得る唯一の方法です）、そしてあなたがすでに何度も解決した退屈な日々のものではなく、楽しいビットのための時間を見つけることを願っています以上。
もちろん、重要なことの後半も重要です。仕事が増えるほど、考える時間を費やす必要がなくなります。
以下は、Rein Henrichs（シンプルでリファクタリングを開始）とammoQ（タイムボックス）による提案を組み合わせた戦略です。
x、それをに絞り込んでからstring、name時間が経過するまで続けます。userHandleこのアプローチの可能な利点：
調査を終えて、明確な最良の選択肢が残されていない場合、時間制限（通常は5分）を選択して1つを選択し、そのまま進めます。 障害にぶつかったとしても、この時点では保証はありません。別の決定を下しても同じ障害にぶつかることはないでしょう。私は自分の決断を後悔している時間を考えることはできません。
通常、判断できない理由は、違いがわずかであるか、十分な情報がないことです。
a）考慮すべき合理的なオプションを考え出すために時間制限を設定します。どちらをまだ決めないでください。時間の終わりに、識別されたオプションの1つ（明確な優先権がない場合はランダムに）と別の時間制限を選択します。時間の終わりに明確な決定がなされない場合、すでに選択されているものがそうです。コーディングを開始し、明らかに間違いがある場合はリファクタリングします。上司がその理由を尋ねた場合、「コインを裏返しました、あなたはより良い方法を手に入れましたか？」と言います。
ケースb）で-あなたはより多くの情報を必要とし、あなたの大きな脂肪A ....に座って一日中それを提供するつもりはありません。設計モードを終了し、情報収集モードに入ります。プロトタイプ、質問、技術雑誌を読んでください。何をするにしても、寝すぎないでください。
多くの場合、最善の解決策は、同僚に決定を説明してみることです。ただし、これを頻繁に行うことは望ましくないので、紙/ペンまたは空のメモ帳ウィンドウのいずれかで、紙の上で考えるのが次善策です。
絶対に何でも書くことから始めてください-ただ書くことのリズムに入るために。メモ帳ウィンドウで、「紙の上で考えています」と入力するだけで、意識の流れを続けることができます。数秒後にライティングのリズムになりますので、Enterキーを数回押して、ジレンマの説明を始めます。
問題を述べ、次に可能な解決策、それぞれの利点などを述べてください。
常に機能するとは限りませんが、頭（RAM）から外部メディア（メモ帳ドキュメント）に思考を移すプロセスにより、新しい接続を作成したり、さまざまな視点から決定を表示したりする自由度が高まります。
私は同じ問題に苦しんでいます。小さな問題については、私がそれに対処しようとする方法は、それが愚かではないと思う最初のデザインを採用することです。最適な設計を見つけようとしても意味がありません。考えずに考えてしまうかもしれないデザインのすべてのニュアンスについて、それを書かずに推論することは不可能ではないにしても困難です。コードを作成すると、少し改善できることがわかります。正しく完了しました。この方法でかなり良いソリューションに収束することはかなり簡単です。
より大きな問題については、最初にオプションを検討することにはメリットがあると思いますが、タイムボックスを使用してください。大きな問題には大きな解決スペースがあり、すべての可能性を評価することはできません。
TLDR; 合理的な解決策を選び、それを改善していきます。
これも関連しています。
陶芸の先生は初日にクラスを2つのグループに分けていると発表しました。彼は、スタジオの左側にいるものはすべて、彼らが生産した作品の量だけで評価され、右側のものはすべてその品質だけで評価されると彼は言った。彼の手順は簡単でした。クラスの最終日には、バスルームスケールを持ち込み、「数量」グループの作業の重量を量ります。しかし、「品質」に格付けされている人は、「A」を獲得するために、完璧なポットではありますが、たった1つのポットを生産する必要がありました。
さて、採点の時が来て、奇妙な事実が浮上しました。最高品質の作品はすべて、数量で採点されるグループによって作成されました。「量」グループは仕事の山を忙しくかき回している間-そして彼らの過ちから学んでいる間-「質」グループは完全性について理論化して座っていたようであり、最終的には壮大な理論と死んだ粘土の山。
http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html。
私はこれを理解したことがありません。私がインストラクターだったとき、私は次のようなことを言うでしょう：
"OK, create an integer variable and assign the return value of strlen() to it."
それほど複雑ではない、あなたは思うかもしれません、そして、人々の95％は次のようなものを書きました：
int x; // or y, or len, or whatever
x = strlen( s );
しかし、時折、ヘッドライトで麻痺したウサギのように座っている人がいるでしょう。私は同情的に問題が何であったか尋ね、彼らは「私はそれを何と呼ぶべきかわからない！」と言うでしょう。
これらは、別のキャリアを探すべき人々です。たぶんあなたがすべきです。