プログラマがコードを書き始める前にアルゴリズムを設計する方が良いのはなぜですか？
適切なアルゴリズムは本当にプログラムの質、そして最終的には効率を改善するのに役立ちますか？
アルゴリズムがなくても、良質のプログラムを作成できますか？
最新のプログラミングでは適切なアルゴリズムが必須ですか？
この質問には、いくつかの歴史的展望が必要だと思います。
「昔」（私は個人的な目撃者ではないので、これはあくまでも私の時代の再構築です。あなたが別のことを経験した場合は、遠慮なく私を修正してください）HWスペースとパフォーマンスは、今日と比較してゼロでした。つまり、すべて人々が書いたものは、非常に効率的でなければなりませんでした。したがって、彼らは仕事を成し遂げるために必要な空間/時間パフォーマンスを達成するための最良のアルゴリズムを発明するために多くのことを考え、研究する必要がありました。これのもう1つの要因は、開発者が主にあなたが呼ぶかもしれないものに取り組んでいることでしたインフラストラクチャ：オペレーティングシステム、プロトコルスタック、コンパイラ、デバイスドライバ、エディタなど。これらすべては多くの人々によって多く使用されています、それでパフォーマンスは本当に違いを生みます。
最近では、基本的なラップトップ（携帯電話でも）でも、マルチコアプロセッサとギガバイトのメモリを備えた信じられないほどのハードウェアを手に入れられなくなっています。これは当然、多くの場合、パフォーマンス（つまりアルゴリズム）が中心的な問題ではなくなったことを意味し、高速なソリューションを提供するよりも、迅速にソリューションを提供することが重要です。 OTOHには、問題の解決に役立つ多数のフレームワークがありますそして多数のアルゴリズムをカプセル化と同時に。そのため、アルゴリズムについて考えていなくても、バックグラウンドで多くのアルゴリズムを使用している可能性があります。
ただし、パフォーマンスが重要な領域はまだあります。これらの領域では、コードを書く前にアルゴリズムについて多くのことを考える必要があります。その理由は、アルゴリズムが設計の中心であり、周囲のコードの多くのデータ構造と関係を決定するためです。そして、あなたのアルゴリズムがうまくスケーリングしていないのが遅すぎることがわかった場合（例えば、それはO（n３）10個の項目でテストしたところ、見た目は素晴らしく高速でしたが、実際には数百万になるでしょう）、量産コードで置き換えるのは非常に難しく、エラーが発生しやすく、時間がかかります。そして、基本的なアルゴリズムが仕事に適していない場合、マイクロ最適化はあなたを助けにはなりません。
何かを指摘するだけです：
アルゴリズム自体は、問題の一般的な段階的な解決策です。したがって、問題を解決した場合、実際にはアルゴリズムを使用しました。
ここで最も重要な点は、アルゴリズムを使用して問題を解決する必要があるということです。ほとんどの場合、コーディングにジャンプする前に問題について考えることをお勧めします。このフェーズはしばしば設計と呼ばれます。しかし、これをどの程度、どのように行うかは、あなた次第です。
また、アルゴリズムの概念を flowcharts と混在させないでください（これはここで起こっていると思います）。フローチャートは、アルゴリズムを説明するために以前から使用されていた1つのグラフィック表現にすぎません。今日ではほとんど非推奨です。
編集：
確かに、アルゴリズムを表す方法はたくさんあり、プログラミング言語コード自体もその1つです。ただし、問題全体を一度に解決するのではなく、単にアウトラインを作成してから、必要に応じて空白を埋める方が、多くの場合、はるかに優れているか簡単です。
ここでの私の個人的なお気に入りは疑似コードであり、問題のアルゴリズムの一般的な抽象的な概要をカバーするだけです-pseudocodeで詳細に入るのはばかげています、それは実際のコードの目的。
ただし、アウトラインには実際のコードを使用できます。たとえば、TDDの人々はコーディングしながらアルゴリズムを設計することを好み、一度にすべてを解決することもできないため、実際のコードでプログラム実行の概要を設計し、を使用します。後で埋められる空白としてオブジェクト（または関数、メソッド...）をモックします。
UMLアクティビティ図は、ポリモーフィズムやマルチスレッドなどの新しいものの表記法が追加された、古いスタイルのフローチャートの現代的な化身のようです。あまり使用していなかったので、これがどれほど便利かはわかりませんが、完全を期すために言及しています。
また、アルゴリズムを状態の切り替えに基づいている場合は、状態図が非常に役立ちます。
一般に、特定のアルゴリズムの背後にあるアイデアを簡単にスケッチする必要があるという意味は、良い方法です。
良い例えは、料理を始める前にレシピを知っている必要があることです。 Ok行くときに調整することはできますが、始める前に何を作りたいかを知る必要があります。ラムシチューを作りたい場合は、パンを焼きたいのですが。
言語に堪能であることは、品質と生産性の向上に役立ちます。小さなアルゴリズムの問題を解決することは、同じMVCを100回繰り返すよりもはるかに便利です。
ただし、流暢さを実現する方法は他にもあると思います。
アルゴリズムは現代のプログラミングドメインで必須になりますか？
「クールなcodez」を書いている「php忍者」でない限り、これはすでに「必須」です。すべての「最高の」企業（Google、Amazonなど）は、インタビューでアルゴリズムの経験をテストしますが、彼らが理由もなくそれを行うことはないと思います。
しかし、元のポイントに戻ると、改善したい場合は常に自分自身に挑戦する必要があります。また、通常のジョブ（別名「100個以上のオブジェクトのCRUDマネージャを作成する」）は必ずしも適切な課題を提供するとは限らないため、アルゴリズムがそれを補正します。
コードはアルゴリズムを実装します。アルゴリズムを設計せずにコードを記述しようとすることは、壁が構築される前に家をペイントしようとするようなものです。アルゴリズムはプログラミングの開始以来「必須」でした。
コーディングを始める前に、少なくともアルゴリズムの最初のアイデアが必要だと思います。データ構造などに基づいてコーディングしているときに、アイデアを修正する可能性があります。
プロファイリングでその領域にパフォーマンスの問題があることが示唆された場合は、後でコードを再度修正できます。
その理由は、間違ったコードを書く前に間違いを修正する方が早いからです。
もっとプローシェニックに言うと、異なるプログラマー間で日常的に測定される10対1の生産性の違いがあります。 10倍の生産性レベルのプログラマーを見ると、実際のコーディングに最小を費やしています。コードを入力する時間がボトルネックになることはありません。代わりに、彼らは自分の時間の大部分を、まっすぐな要件、計画、テストなどがあることを確認することに費やしています。
逆に、休止することなくコーディングに飛び込むプログラマーを見ると、完全に予見可能な問題が発生するため、必然的にコードを何度も何度も書く必要があり、最終結果は保守性が低下し、バグが多くなります。 （ちなみに、ソフトウェア開発に費やされた費用の平均80％が保守フェーズにあることをご存知でしたか？物事を保守可能にすることは重要です。）
一般に、アルゴリズムとデータ構造を最初に、後でコード化します。しかし、それはプログラミングドメインに大きく依存します。多くの応用数学タイプのことをやっていましたが、当時流行していたウォーターフォールモデルを見下ろしていました。これは、低レベルから中レベルのアルゴリズムが当然のことと見なされることはめったにないためです。未作成のサブシステムの存在を中心に大きな構造を設計し、ゲームの後半で、これらの重要なサブシステムのいずれかの計算がうまくいかない（不安定であるなど）ことを発見します。したがって、私は常に最も困難なサブシステムについて常に最初に考え、疑わしい理由がある場合は、最初にそれらを記述してユニットテストを行いました。しかし、一部の問題のあるドメインでは、多くの計画を立てなくても先に進むことができます。
私にとって、それはほとんどすべてのコードです。これは、最も生産性の高いプログラマに当てはまると思います。テキストを書くのと同じくらい簡単にコードを書くことができます。
可能な限り、要件を実行可能なテスト（コード）としてキャプチャするようにしています。設計は単なる高レベルのコーディングです。デザインを他の形式でキャプチャして翻訳するよりも、ターゲット言語でデザインをキャプチャする方が高速かつ正確です。
ほとんどのユーザーはテキストの要件を効果的に確認できないことがわかりました。一連のユースケースで問題ありませんが、ユースケースはUIのすべての側面をキャプチャできるわけではありません。断然最善の方法は、実装時に最初のカットを行い、ユーザーに試してもらい、コメントをもらい、それに応じてコードを変更することです。
アルゴリズムをセクションで設計し、それらのセクションを分割して、それぞれを個別にコーディングします。そうすれば、両方の視点を組み合わせることができます。
- 言語機能を使用してアルゴリズムを機能させる
- コードの前に考えるようにしてください。そうすれば、アイデアが言語に統合されません（ある日、アルゴリズムを別の言語に移動する必要があり、spagetthiで終わります）。
座ってコーディングを開始すると、「設計されている」かどうかに関係なく、アルゴリズムが頭に浮かびます。
完全なアルゴリズムを考慮せずに座ってコーディングを開始した場合、次のいずれかを実行することになります。
1）キーをランダムにマッシュする。これはおそらくコンパイラエラーを生成します
2）おそらくあなたがやりたいこと以外のことを何でもするコンパイル可能なコードを書く
3）問題のほんの一部を解決するコードを記述し、集約的な方法で進んでいく上で構築しますが、実際には前向きに考えていません。途中で逆戻りして時間を無駄にする可能性
したがって、人々は通常、頭の中でアルゴリズムを使ってプログラミングします。紙やその他の媒体で肉付けされているか、それについて推論されている可能性があります。
特にプログラマーとしての初期の段階では、キーボードから離れた問題に対する攻撃について考えることは良い規律になる可能性があります。他の回答が指摘しているように、経験を積むにつれて、「オンザフライ」で問題のより扱いやすいチャンクのコーディングをよりよく行うことができます。ただし、困難な問題や大きな問題の場合は、キーボードから離れて考えて設計することが役立ちます。コードを使用するときは、言語の構成要素の観点から、また、最も直接的なタスクにアプローチする方法について考える可能性が高くなります。問題。たとえば、ペンと紙で問題を考えると、コードの言語的な側面から解放され、より抽象的なレベルで考えることができます。
ソフトウェアの構築を、他の価値のあるものの構築から根本的に何かと見なすのをやめる必要があります。そうではない。したがって、他のすべてと同様に、十分に検討された計画または設計は、どんなに簡潔でも常に必要です。
適切なアルゴリズムは、プログラムの品質と最終的には効率の向上に本当に役立ちますか？
適切な建築計画/回路図は、高品質の家を効率的に建築するのに役立ちますか？
アルゴリズムがなくても、良質のプログラムを作成できますか？
適切な建築計画なしで、良質の家を効率的に建てることができますか？ Infinite Monkey Theorem のように、確率的にそうです（永遠に無作為に入力する100万匹のサルが最終的にシェイクスピアの全作品を入力するように）。
最新のプログラミングでは適切なアルゴリズムが必須ですか？
コードモンキーになりたくなく、たわごとのように機能するソフトウェアを提供しないようにしたい場合は、そうです。私がサルベージしなければならなかったすべてのプロジェクト（コードがumintainableたわごとのように見えたため）は常に、その質問に対する否定的な答えから始まりました。
実際、現代のプログラミングは、ある種の計画を計画しているカウボーイプログラミングソフトウェアエンジニアからの移行でした必要な場合。
アルゴリズムとデータ構造のライブラリを自由に使用できる場合（つまり、C++のBoostまたはJavaコレクションライブラリ））でも、それが適切に使用されるように機能する方法を知っている必要があります。そしてそれを合理的で高レベルのアルゴリズムに構成する。