矛盾するプログラミングのアドバイスを調整する：何かを機能させ、反復するか、コーディングする前に実際に考えるか
私は、修士号の途中で数年のプロの経験を持つ中級プログラマーです。プログラムの学習中に、一見矛盾する2つのアドバイスをよく耳にしました。
最初のアドバイスは、何かをすばやく動作させること、それがどのように機能するか（プロトタイピングまたは非公式のテストを通じて）、バージョンを改善すること、それがどのように機能するかを確認し、もう一度改善することでした...そして、完了するまでサイクルを繰り返す。これは「スパイラル開発」と呼ばれることもあり、「早期にリリースされ、頻繁にリリースされる」と表現されることもあります。
2番目のアドバイスは、コードを書く前にプロジェクトをよく考えます。
私は両方の方法で成功しましたが、私はそれぞれの哲学に同意します。
しかし、今では、どのようにすれば完了できるかわからない、はるかに複雑なプロジェクト（分散アプリケーションやパフォーマンス主導のグラフィックプログラミングなど）に取り組み始めています。
これらのプロジェクトについてどうやって進めますか？
何かをコーディングし始めて（プラットフォーム/メソッド/言語/アーキテクチャ）を学ぶだけでいいですか？それとも、IDEを開く前にコーディングを控え、大量の調査/読書を行いますか？
これらの矛盾するプログラミングアドバイスを調整するにはどうすればよいですか？
事前に問題を考えることと、反復的なアプローチとを比較することが互いに矛盾しているとは思いません。他の多くのものと同じように、私はあなたが両者のバランスを達成するために努力すべきだと思います。どのようにバランスをとっていますか？これは、経験を積んで習得したものであり、多くの場合、最良のレッスン（つまり、経験を提供するもの）は、正しく理解していない場合（または、さらに良いレッスン：完全に間違っている場合）です。あなたがすでに指摘したように、「速くリリースし、頻繁にリリースする」という言葉があります。他にも似たものがあります "早期に失敗し、速く失敗し、頻繁に失敗します"
先を考えることは素晴らしいので、絶対にやるべきです。しかし、経験があれば、考えるのをやめ、すべてのデータがなくても何かを構築するタイミングを学びます。それを構築することで、問題の領域をより深く理解し、潜在的にはるかに優れた解決策を考え出すことができます。ですから、一方を他方から除外するのではなく、「思考の頭」を反復の一部にすることをお勧めします。やがて、この質問に対する正しい答えを自分で見つけることができると思います。
ほんの少しの例。先日、ソフトウェア設計の決定に苦労していました。後から考えるとそれは比較的些細なことでしたが、私には2つの選択肢があり、どちらも機能するようでした。私はそれぞれの長所と短所に戻って回り、その後自分の決定を再検討しました。振り返ってみると、私が考えていた時間がどれほど恥ずかしいのですか。それから私は自分に言いました、f＃@ k it！そして、どちらかのデザインを使用する代わりに、私は先に進んでいくつかのコードをハッキングし、優れたデザインについて学んだすべての優れたものを完全に無視しました。機能は約45分で動作しました。その後、戻ってコードを確認し、ソース管理にチェックインすることを恥ずかしくないものにリファクタリングしました。面白いのは、ハックを機能させた後、「適切な設計」を思いつくのに約15分かかったことです。
私が特に直面している問題（つまり、迫り来る大規模で複雑なタスク）について特にお勧めします。物事をシリアルで行う代わりに、パラレルで行います。少なくとも完全な未知数ではないプロジェクトの一部について、研究を行ってから停止し、しばらくの間ギアとコードを切り替えてチャンクに1日を分割します。この方法を使用すると、コードの近くに留まることで、より良い視点が得られ、あまりに多くの情報を速く吸収しすぎて燃え尽きることはありません。少なくとも私にとっては、数時間の研究の後、脳にものを消化させ、タスクを切り替え、しばらくの間他のことをするのは良いことです。その後、より多くの研究に戻ってください。
事前に決定する必要がある特定の決定があります。
Webアプリケーションを作成していますか？次に、全体的なアーキテクチャがどのようになるかを知る必要があります。 MVCのようなアーキテクチャーは、大規模な機能部分が何になるかをすでに定義しています（ルーティング、コントローラー、モデル、サービス層、通信プロトコルなど）。これらすべてをゼロから発明することは、長期的には不要であり、おそらくすでに発明されているものよりも劣ります。
オブジェクトまたはデータのコレクションを含むアプリケーションを作成していますか？次に、特定のシナリオに最も適したデータ構造の種類と、そのパフォーマンス特性を把握する必要があります。高速な検索時間が必要ですか？順序付けられたデータセットはどうですか？インメモリコレクションは機能しますか、それともデータベースのようなより強力な機能が必要ですか？これらの決定をじっくり考えずにコーディングを始めることはできません。間違った選択をすると、最初からやり直す必要があるからです。
とはいえ、技術的な決定が下されると、確立したフレームワーク内で自由が生まれます。その場合の目標は、柔軟性、反復性、そして（あえて言うと）十分な俊敏性を維持し、顧客が望むものについて考えを変えたときに、最小限の手間で対応できるようにすることです。
どうやってやるの？経験、ほとんど。誰かが言ったように、経験はあなたがそれを必要としたらすぐに得られるものです。しかし、（プラットフォーム、ライブラリ、その他の業界のツールで具体化されているように）他の人が成功した設計上の決定に従うと、それらから学び、リスクを減らすことができます。
「反復」と「それを考える」は矛盾せず、相補的です。
極端な場合でも、同じ場所に到達するための2つの経路を反映しています。
- イテレーションの極端な例は、千匹のサルが千匹のキーボードを叩き鳴らすことです。十分な時間があれば、要件を満たすものが得られるでしょう。
- 「考え抜く」の極端は、ウォーターフォールアプローチです。運が良ければ、コードを提供するまでに、プロジェクトの開始時から要件が劇的に変わっていません。または、分析麻痺に終わり、何も提供されない場合もあります。
コーディングを開始する前に、ドメインと問題についてある程度理解しておく必要があります。これは「考える」部分です。理想的には、問題を解決する方法の最初から最後までの高レベルのパスが表示されます。
しかし、あなたはその道の主要な部分だけを見るかもしれません、そして確かにすべてが途中で止まるわけではありません。ここで反復が始まります。次の目的で、アプリケーションのバージョンを繰り返し処理し、フィードバックを求めることができます。
- より低い詳細レベルで発生する障害を特定する
- ハイレベルパスのあいまいな領域を明確にするために、利害関係者のフィードバックを参照してください。
決定のラテン語のルート は、「切り捨て」を意味します。反復により、理論だけでなく実際に機能するものを決定でき、反復により、実行不可能な他のオプションを削除できます。
したがって、何をしようとしているのかを理解するために、問題をじっくりと考える必要があります。ただし、アイデアを実際のコードに実際に変換するには、アプリケーションのバージョンを繰り返し処理する必要があります。
この2つを相互に排他的であるとは考えていません。
あらゆる種類のプロジェクト管理と同様に、長期的なビジョンと短期的な目標の両方が必要です。
前者がなければ、たとえば使用することさえできない機能に時間を浪費することになり、後者がないと、プロジェクトを終了せずに完璧なアプリケーションを作成する方法を検討することに1日を費やすことになります。
リリースする頻度など。使用している特定の方法論に依存します。
何を研究する必要があるかは、あなたが何を知っているか、何を不快に思っているかによって異なります。
私の経験則：問題の一部を完全に理解していない場合は、一歩下がって完全に考える必要があります（「考える」の一部として、APIなどを理解するためのプロトタイピングと使い捨てのコードを含めます）。 。それが基本的に以前に解決した問題のコレクションであり、この特定のインスタンスですべてを組み合わせるための最良の方法を見つける必要がある場合は、繰り返します。
正直なところ、それは難しくて速い規則ではありません。どのプロジェクトでも、両方を組み合わせて実行する必要があると思います。どれだけの作業を行うかは、ほとんどの場合、プロジェクトが過去に完了したプロジェクトにどれだけ近いかに依存します。