圧力がかかっているときにソリューションにジャンプしないようにする方法は？[閉まっている]

特に厳しいプログラミング期限（1時間など）にあるとき、私がまったくパニックに陥った場合、私の傾向は実際の計画なしにコーディングに飛びつき、私が進むにつれてそれを理解することを望みます。十分な時間を与えられれば、これはうまくいく可能性がありますが、インタビューでは、まったく逆効果ではないとしても、かなり失敗しました。時計が時を刻む間、私はそこに座って考えるのがいつも快適ではありません。

チェックリストはありますか、またはコーディングを開始するのに十分なほど問題を理解したときに認識するテクニックはありますか？いくつかの実験をコード化してより多くのことを考えて設計し、後で全体的な設計を理解することが最も生産的ですか？

ここに数学試験を受けるためのテクニックと口頭試験を受けるための別のリストがあります。プレッシャーのかかったプログラミング問題を処理するための同様のテクニックのリストはありますか？

回答：これは有効な答えだと思います：解決方法。私はそのリンクが解決策に向かって解決またはアプローチするためのステップへの答えとして見つけました。でいくつかの本当に良いヒントもあった本当にインタビューの最善の戦略中に大声で考えているのは？。TDDの素晴らしく簡潔な議論は、TDDに対する最初の答えです。。

私は、火のマーシャルが火の現場に到着したときに行動計画をどのように形成するかに関する研究を読んだことを思い出します。この研究では、アイデアを思いついたために彼らを観察し、非難しました。そして、その最初のアイデアをすぐに追求しました。時間のプレッシャーのため、「これでうまくいくかもしれません」、「OK、やってみよう」が続きました。この研究は、より良く、より速く、より安全な選択肢が利用可能であると指摘したが、マーシャルが最初にそれらを考えなかったという理由だけで、それらは従われなかった。

「火事」に対処するための構造化されたアプローチが必要な場合は、いくつかのフェーズを規定する（新しい）本から葉を取り除いてください。

ラピッド

1. 反応-リソースをインシデントに動員する
2. 偵察-状況に関するデータを収集する
3. 感謝-最良のシナリオと最悪のシナリオに基づいて一連の行動を選択する
4. 計画-行動方針に基づいて計画を策定する
5. 注文の発行-標準のブリーフィング形式を使用
6. 展開-実行および監視

またはより一般的な用語で：

1. みんなを起こして動かして
2. 何が起こっているのかを把握する
3. ブレインストーミングソリューション
4. 1つを選んで計画する
5. 全員に自分の仕事を教えてください
6. 実行および監視

私は常に要件を理解し、答えが必要なギャップを探すことから始めます。

次に、2つまたは3つの可能な解決策をスケッチします（非常に大まかに、紙またはホワイトボードで）。次に、「これらのいずれかを実装するために知っておくべきことは他にありますか？」と自問します。

最初の質問があれば（100％の質問があります。質問がない場合は、要件を詳しく調べていません。）、利害関係者に戻って回答を得ます。

私は彼らの回答を待っていますが、自分の解決策を検討し、他の解決策よりも優れているか、質問に対する回答が得られたら改善されるかを確認します。たとえば、どのくらい早く質問が必要なのかがすぐにわかる場合は、開発が最も速いものを探しますが、後で設計を改善する方法を残しておきます。パフォーマンスが重要だと言われたら、ソリューションを見て、どちらがパフォーマンスが向上する可能性が高いかを判断します（これらはこの時点での推測ですが、一般的には情報に基づいたものです）。GUIが関係する場合、いくつかの異なるデザインの紙のプロトタイプを作成し、何かをコーディングする前に関係者にそれらを見てもらうことができます（通常、設計！）

回答が得られたら、大まかな設計を選択し、それを実装するために必要なすべてのことのリストを作成します。次に、コーディングを開始します。

...私の傾向は、実際の計画なしにコーディングに飛び込むことであり、私が進むにつれてそれを理解することを願っています

大学在学中にこれをやった。それは実際の問題になり、通常はコードの書き換えにつながります。私はコードを書かないことでこれに取り組み始めました。私は問題についての考えに重点を置きました。十分に練習すれば、キーボードではなく本能的に考えに手を伸ばすことができます。

...インタビューでは、実に非生産的ではないとしても、かなり失敗しました。時計が時を刻む間、私はそこに座って考えるのがいつも快適ではありません。

インタビューの中で、解決策に対する合理的で熟考された実装が必要であり、それは必ずしも容易ではありません。あなたがしたくないことは、考えずに答えを曖昧にすることです。答えがわかっている場合は、すぐに答えてください。そうでない場合は、解決策を考えるためにあなたの考えに頼ってください。 不明な場合は常に示し、解決策を見つける方法を示してください。

チェックリストはありますか、またはコーディングを開始するのに十分なほど問題を理解したときに認識するテクニックはありますか？

あなたがそれを厳しく頼ることがあるので、私はそのようなことを思いとどまらせます。むしろ、コーディングを開始するのに十分な問題を理解しているかどうかを自問してください。どうやって知る？なぜなら、あなたのアプローチを推論し、それを調べるとき、あなたの現在の言語の知識を考えると、それは理にかなっているからです。常に計画とアプローチを用意してください。また、コードが完成することはなく、進化しなかったコードは死ぬので、頻繁にコードに戻ることを期待してください。

いくつかの実験をコード化してより多くのことを考えて設計し、後で全体的な設計を理解することが最も生産的ですか？

全体的な設計を知り、それを考えてください。次に、クラス構造とスタブの作成を開始します。その後、もう一度確認します。理にかなっていますか？コーディング実験は、何かがうまく機能することを実証するのに最適な方法であり、使用する必要がありますが、作成するコードの作成や形成に依存するものではありません。