矛盾するプログラミングのアドバイスを調整する：何かを機能させて反復するか、コーディングする前に実際に考える

私は、修士号の中間にある数年のプロの経験を持つ中級プログラマーです。プログラミングを学ぶ際に、一見矛盾していると思われる2つのアドバイスをよく耳にしました。

最初のアドバイスは、何かをすばやく動作させ、それがどのように機能するかを（プロトタイプまたは非公式のテストを介して）確認し、バージョンを改善し、再び機能する方法を確認し、再び改善し、それが完了するまでサイクルを繰り返すことでした。これは「スパイラル開発」と呼ばれることもあれば、「早期リリース、頻繁にリリースする」と表現されることもあります。

2番目のアドバイスは、コードを記述する前にプロジェクトを実際に検討することでした。

私は両方の方法で成功しており、それぞれの哲学に同意すると言うでしょう。

しかし、今では、完了方法がわからないはるかに複雑なプロジェクト（分散アプリケーションやパフォーマンス駆動型グラフィックプログラミングなど）に取り組み始めています。

これらのプロジェクトについてはどうすればいいですか？

コーディングを開始して、（プラットフォーム/メソッド/言語/アーキテクチャ）を学習しながら学習しますか？それとも、IDEを開く前にコーディングを控えて大量の調査/読み取りを行いますか？

これらの矛盾したプログラミングのアドバイスをどのように調整しますか？

前もって問題を考えるか、反復アプローチを考えるかは、互いに矛盾しているとは思いません。他の多くのことと同じように、この2つのバランスをとるよう努力する必要があると思います。どのようにバランスを見つけますか？それは経験を積んで学ぶことであり、多くの場合、時間のベストレッスン（つまり、経験を積むもの）は、あなたがそれを正しく理解していないときです（あるいは、より良いレッスン：間違ってしまうだけです）。既に指摘したように、「早くリリース、頻繁にリリース」という言葉があります。もう1つ類似したものがあります。「早期に失敗し、速く失敗し、頻繁に失敗します」

先を考えることは素晴らしいことであり、絶対にやるべきです。しかし、経験があれば、すべてのデータがなくても、思考をやめ、何かを構築するタイミングを学びましょう。それを構築することにより、問題の領域についてより多くの洞察を得ることができ、潜在的にはるかに優れたソリューションを思いつくことができます。したがって、一方を他方から除外せずに、「思考の頭」を反復の一部にすることをお勧めします。時間の経過とともに、この質問に対する正しい答えが自分で見つかると思います。

ほんの一例です。先日、ソフトウェア設計の決定に苦労していました。後から考えると、それは比較的些細なことでしたが、2つの選択肢があり、両方とも機能するように思えました。私はそれぞれの長所/短所に戻って回り続け、それから戻って回り、決定を再考しました。振り返ってみると、私が考えるのにどれだけの時間を費やしたかが少し恥ずかしいです。それから私は自分に言った、f＃@ k it！そして、いずれかの設計を使用する代わりに、私は先に進み、いくつかのコードを一緒にハッキングし、良い設計について学んだすべての良いものを完全に無視しました。この機能は約45分で機能しました。それから私は戻って、自分のコードを見て、それをしっかりした何かにリファクタリングし、ソース管理にチェックインすることを恥ずかしく思わない何かにリファクタリングしました。面白い部分は、ハックが機能した後、「

あなたが今直面している問題（すなわち、大規模で複雑なタスクが迫っています）のために私が特にお勧めしたいこと。物事を順番に行う代わりに、それらを並行して行います。少なくともプロジェクトの一部で、完全な未知の部分ではない場合、1日をチャンクに分けて調査を行い、その後停止し、しばらくの間ギアとコードを切り替えます。このようにコードの近くにとどまると、見通しがよくなり、あまりにも多くの情報をすばやく吸収しようとすることで燃え尽きません。少なくとも私にとっては、数時間の研究の後、脳に物質を消化させ、タスクを切り替え、しばらくの間何か他のことをさせるのは良いことです。その後、さらに調査に戻ります。

事前に決定する必要がある特定の決定があります。

Webアプリケーションを作成していますか？次に、全体的なアーキテクチャがどのようになるかを知る必要があります。MVCのようなアーキテクチャは、大規模な機能部分（ルーティング、コントローラー、モデル、サービスレイヤー、通信プロトコルなど）を定義しています。すべてをゼロから発明することは、長距離で、不必要であり、おそらく既に発明されているものよりも劣っています。

オブジェクトまたはデータのコレクションを含むアプリケーションを作成していますか？次に、特定のシナリオに最適なデータ構造の種類と、それらのパフォーマンス特性について知る必要があります。高速な検索時間が必要ですか？順序付けされたデータセットはどうですか？メモリ内のコレクションは必要ですか、それともデータベースのようなより強力なものが必要ですか？間違った選択をした場合、最初からやり直す必要があるため、これらの決定を熟慮せずにコーディングを開始することはできません。

つまり、技術的な決定が下されると、確立したフレームワーク内で自由が得られます。目標は、柔軟性、反復性、および（あえて）俊敏性を維持し、顧客が望むものについて考えを変えたときに、最小限の手間で顧客に対応できるようにすることです。

どうやって？主に経験。誰かがかつて言ったように、経験はあなたがそれを必要とした直後に得られるものです。しかし、他の人の成功した設計決定（プラットフォーム、ライブラリ、および取引の他のツールで具体化される）に従うと、それらから学び、リスクを減らすことができます。

私はこの2つを相互に排他的ではないと考えています。

あらゆる種類のプロジェクト管理と同様に、長期的なビジョンと短期的な目標の両方が必要です。

前者がなければ、たとえば使用されることさえない機能に時間を浪費し、後者がなければ、プロジェクトを完成させずに完璧なアプリケーションを作成する方法を検討するために一日中費やします。

リリースなどの頻度。使用している特定の方法論に依存します。

あなたが研究しなければならないことは、あなたが知っていることと、あなたが慣れていないことによって異なります。

「反復」と「考え抜く」は矛盾するものではなく、補完的なものです。

極端な場合でも、同じ場所に到達するための2つのパスを反映しています。

• イテレーションの極端な例は、1000匹の猿が1000匹のキーボードを叩いていることです。十分な時間があれば、要件を満たすものが得られるでしょう。
• 「考え抜く」という極端な方法は、ウォーターフォールアプローチです。運がよければ、プロジェクトを開始してからコードを配信するまでに要件は劇的に変更されていません。または、分析の麻痺に陥り、何も配信されない場合があります。

コーディングを開始する前に、ドメインと問題をある程度理解する必要があります。これは「考える」部分です。理想的には、問題の解決方法の最初から最後までの高レベルのパスが表示されます。

しかし、あなたはその道の主要な部分だけを見るかもしれません。それがイテレーションの出番です。次の目的で、アプリケーションのバージョンを反復処理し、フィードバックを求めることができます。

• 下位レベルの詳細に現れる障害を特定する
• 利害関係者のフィードバックを参照して、高レベルの経路にあるこれらの不明瞭な領域を明確にしてください。

決定のラテン語ルートは、「切断」することを意味します。反復により、理論だけでなく実際に機能するものを決定でき、反復により、実行できない他のオプションを除外できます。

だから、あなたは何をしようとしているのかを理解するために問題を熟考する必要があります。しかし、アイデアを実際のコードに実際に変換するには、アプリケーションのバージョンを反復処理する必要があります。

私の経験則：問題の一部を完全に理解していない場合は、戻って十分に検討する必要があります（APIを理解するためのプロトタイピングとスローアウェイコードを「考え抜く」の一部として含めます） 。それが基本的に以前に解決した問題のコレクションであり、この特定のインスタンスですべてをまとめる最適な方法を見つけ出す必要がある場合は、繰り返します。

正直なところ、それは難しい規則ではありません。どのプロジェクトでも、両方を組み合わせて行う必要があると思います。どれだけの作業を行うかは、おそらく、プロジェクトが過去にすでに完了したプロジェクトにどれだけ近いかに依存するでしょう。