プログラマーがコードを書き始める前にアルゴリズムを設計する方が良いのはなぜですか？

適切なアルゴリズムは、プログラムの品質を改善し、最終的には効率を改善するのに本当に役立ちますか？

それでもアルゴリズムなしで良質のプログラムを作成できますか？

現代のプログラミングでは適切なアルゴリズムは必須ですか？

この質問は歴史的な見方を示していると思います。

「昔」に戻ります（私は個人的な目撃者ではないので、これはその時代の再構築に過ぎません-物事が異なる場合はお気軽に修正してください）HWのスペースとパフォーマンスは今日に比べてゼロでした。したがって、人々が書いたものはすべて非常に効率的でなければなりませんでした。したがって、彼らは、仕事を成し遂げるために必要な空間/時間パフォーマンスを達成するための最良のアルゴリズムを発明するために、多くのことを考え、研究する必要がありました。これのもう1つの要因は、開発者が主にインフラストラクチャ（オペレーティングシステム、プロトコルスタック、コンパイラー、デバイスドライバー、エディターなど）と呼ばれるものに取り組んでいることです。これらはすべて多くの人々によって多く使用されているため、パフォーマンスは本当に違いをもたらします。

最近では、基本的なラップトップ（携帯電話でも）でさえ、マルチコアプロセッサとギガバイトのメモリを備えた信じられないほどのハードウェアが台無しにされています。これは当然、多くの場合、パフォーマンス、つまりアルゴリズムが中心的な問題ではなくなり、高速なソリューションを提供するよりも高速にソリューションを提供することがより重要であることを意味します。OTOHには、問題を解決し、同時に多数のアルゴリズムをカプセル化するのに役立つ多くのフレームワークがあります。したがって、アルゴリズムについて考えていなくても、多くのアルゴリズムをバックグラウンドで使用している可能性があります。

ただし、パフォーマンスが重要な領域はまだあります。これらの分野では、コードを記述する前に、アルゴリズムについて多くのことを考える必要があります。その理由は、アルゴリズムが設計の中心であり、周囲のコードの多くのデータ構造と関係を決定するためです。そして、アルゴリズムがうまくスケーリングしていないことが遅すぎるとわかった場合（例えば、O（n ³）で、10個のアイテムでテストしたときに素晴らしく速く見えましたが、実際には数百万個になります）本番コードで置き換えるのは難しく、エラーが発生しやすく、時間がかかります。基本的なアルゴリズムが仕事に適していない場合、マイクロ最適化は役に立ちません。

何かを指摘するだけです：

アルゴリズム自体は、問題の一般的な段階的な解決策です。したがって、問題を解決した場合、実際にはアルゴリズムを使用しました。

ここで最も重要な点は、アルゴリズムを使用して問題を解決する必要があることです。ほとんどの場合、コーディングにジャンプする前に問題について考えることをお勧めします。このフェーズはしばしば設計と呼ばれます。しかし、これをどの程度、どのように行うかはあなた次第です。

また、アルゴリズムの概念とフローチャートを混同しないでください（これはここで起こっていると思います）。フローチャートは、使用できるグラフィカルな表現の1つにすぎず、アルゴリズムを説明するために昔は使用されていました。最近ではほとんど使われていません。

編集：

アルゴリズムを表現する方法は実に多くあり、プログラミング言語コード自体もその1つです。ただし、問題全体を一度に解決するのではなく、アウトラインだけを解決してから、空白を埋める方がはるかに優れているか、または簡単です。

• 私の個人的な好みは、ここでは擬似コードであり、唯一の問題のアルゴリズムの一般的な抽象概要をカバーするために-それはと細部に入るためにばかげて擬似コードのどのような実際のコードの元となりました、。

• しかし、アウトラインには実際のコードを使用できます。たとえば、TDDの人々はコーディング時にアルゴリズムを設計することを好みますが、一度にすべてを解決することもできないため、実際のコードでプログラム実行のアウトラインを設計し、モックオブジェクト（または関数、メソッド）を使用します。 。）後で記入するブランクとして。

• UMLアクティビティ図は、ポリモーフィズムやマルチスレッドなどの新しいものの表記法が追加された、古いスタイルのフローチャートの現代的な化身のようです。私は実際にあまり使用しなかったので、これがどれほど便利かは本当に言えません-完全を期すために言及しているだけです。

• また、状態の切り替えに基づいてアルゴリズムを作成している場合は、状態図が非常に役立ちます。

• 一般的に、特定のアルゴリズムの背後にあるアイデアを簡単にスケッチする必要があるという意味 は、良い方法です。

良い例えは、料理を始める前にレシピを知っておく必要があるということです。[OK]を使用して調整することもできますが、開始する前に何を作成するかを知る必要があります。子羊のシチューを作りたい場合は、一loのパンを焼く場合とは非常に異なることをします。

コードはアルゴリズムを実装します。アルゴリズムを設計せずにコードを記述しようとすると、壁を構築する前に家をペイントしようとするようなものです。プログラミングの開始以来、アルゴリズムは「必須」でした。

あなたの言語に堪能であることは、品質と生産性の向上に役立ちます。また、同じMVCを100回繰り返すよりも、小さなアルゴリズムの問​​題を解決する方がはるかに便利です。
ただし、流さを実現する方法は他にもあると思います。

アルゴリズムは、現代のプログラミングドメインでは必須になるのでしょうか？
あなたが「php code ninja」を書いている「php ninja」でない限り、それはすでに「必須」です。「最高の」企業（Google、Amazonなど）はすべて、インタビューであなたのアルゴリズムの経験をテストしますが、理由もなくそれをやらないと思います。

しかし、元のポイントに戻り、改善したい場合は、常に自分自身に挑戦する必要があります。また、通常のジョブ（「100個以上のオブジェクトのCRUDマネージャーを作成する」）が常に良い課題を提供するわけではないため、アルゴリズムがそれを補います。

コーディングを始める前に、少なくともアルゴリズムの最初のアイデアが必要だと思います。データ構造などに基づいてコーディングしている間に、アイデアを修正する可能性があります。

プロファイリングによってその領域にパフォーマンスの問題があることが示唆された場合、後でコードを再度修正できます。

その理由は、誤ったコードを記述する前に、間違いを修正する方が速いためです。

より普遍的には、異なるプログラマーの間で10対1の生産性の違いが定期的に測定されます。あなたは10倍の生産性レベルであるプログラマを見てみると、彼らが過ごす最小の実際のコーディング自分の時間の割合を。コードを入力する時間がボトルネックになることはありません。代わりに、彼らは彼らがまっすぐに要件、計画、テストなどを持っていることを確認することに彼らの時間の大部分を費やします。

逆に、一時停止せずにコーディングに飛び込むプログラマーを見ると、予測可能な問題に遭遇するため、コードを何度も何度も書く必要があり、最終結果は保守性が低く、バグが多くなります。（ちなみに、ソフトウェア開発に費やされたお金の平均80％がメンテナンスフェーズにあることを知っていましたか？

一般に、最初にアルゴリズムとデータ構造を作成し、後でコーディングします。しかし、それはプログラミングドメインに大きく依存します。私は多くの応用数学タイプのものを使用していましたが、当時の一般的なウォーターフォールモデルを実際に見下ろしていました。これは、低から中レベルのアルゴリズムが当たり前と見なされることはめったにないからです。記述されていないサブシステムの存在を中心に大きな構造を設計し、ゲームの後半で、これらの重要なサブシステムのいずれかの計算がうまくいかないことを発見します（不安定またはその他）。だから私は常に最も挑戦的なサブシステムについて最初に考えました、そして疑わしい理由があれば、私はそれらを最初に書き、ユニットテストしました。ただし、一部の問題のあるドメインでは、多くの計画を立てなくても先に進むことができます。

セクションでアルゴリズムを設計し、それらのセクションを分割して、それぞれを個別にコーディングします。そうすれば、両方の視点を混ぜることができます：

1. 言語機能を使用してアルゴリズムを機能させる
2. コードの前に考えてみてください、あなたのアイデアは言語に統合されません

私にとっては、ほとんどすべてのコードです。これは、ほとんどの生産性の高いプログラマーに当てはまると思います。テキストを書くのと同じくらい簡単にコードを書くことができます。

可能な限り、要件を実行可能テスト（コード）としてキャプチャしようとします。設計は単なる高レベルのコーディングです。他の形式でデザインをキャプチャしてから翻訳するよりも、ターゲット言語でデザインをキャプチャする方が高速で正確です。

ほとんどのユーザーはテキストの要件を効果的に確認できないことがわかりました。連続したユースケースでは問題ありませんが、ユースケースはUIのすべての側面をキャプチャできるわけではありません。一番良いのは、実装を最初にカットして、ユーザーに試してもらい、コメントをもらい、それに応じてコードを修正することです。

座ってコーディングを開始すると、「設計」されているかどうかに関係なく、アルゴリズムが考慮されます。

完全なアルゴリズムを念頭に置かずにコーディングを開始すると、次のいずれかを実行することになります。

1）キーをランダムにマッシングします。これはおそらくコンパイラエラーを生成します

2）おそらくあなたがやりたいこと以外の何かをするコンパイル可能なコードを書く

3）問題のほとんどの部分を解決するためのコードを作成し、集約しながら進めながら、実際に先を考えていないため、最終的に問題は解決されますが、コードはあまり効率的ではありません。バックトラックし、道に沿って時間を無駄にする可能性

そのため、通常、人々は頭の中でアルゴリズムを使ってプログラミングします。紙または他の媒体で肉付けされているか、または推論されている可能性があります。

特にプログラマーとしての初期の頃、キーボードから離れた問題に対する攻撃について考えることは良い規律になります。他の回答が指摘しているように、経験を積むにつれて、管理可能な問題のチャンクを「オンザフライ」でコーディングするのが上手くなります。ただし、困難な問題や大きな問題の場合、キーボードから離れて考えて設計することは有用です。コードを扱うときは、言語の構成要素や、問題。たとえば、ペンと紙で問題を考えると、コードの言語的な側面から解放され、より抽象的なレベルで考えることができます。

ソフトウェアの構築を、価値のある他のものの構築から根本的に何かと見なすのをやめる必要があります。そうではない。だから、他のことと同じように、よく考えられた計画や設計は、どんなに簡潔であっても常に必要です。

適切なアルゴリズムは、プログラムの品質を改善し、最終的には効率を改善するのに本当に役立ちますか？

適切な建築計画/概略図は、質の高い家を効率的に建築するのに役立ちますか？

それでもアルゴリズムなしで良質のプログラムを作成できますか？

適切な建築計画なしで効率的に良質の家を建てることができますか？あたりとして無限の猿定理、確率的に、ええ（永遠にランダムに入力して、同じように万人のサルは、最終的にはシェイクスピアの全作品を入力します。

現代のプログラミングでは適切なアルゴリズムは必須ですか？

コードモンキーになりたくなく、見た目も動作もクソなソフトウェアを提供しないようにしたい場合は、必須です。（コードが保守可能なたわごとのように見えたので）私が救済しなければならなかったすべてのプロジェクトは、その質問に対する否定的な答えから始まって不変です。

実際、現代のプログラミングは、何らかの計画を立てる必要があるカウボーイプログラミングソフトウェアエンジニアから遠ざかっています。

アルゴリズムのライブラリとデータ構造を自由に使用できる場合（つまり、C ++またはJavaコレクションライブラリのBoost）でも、それを適切に使用し、合理的で高いレベルのアルゴリズム。

それは良くありません。何も「設計」しない方が良いです。それはプログラムを書いていない人向けです。ご存知のように、問題を実際に経験している人々です。あなたが数学者、エンジニア、またはロジスティック学者であれば、他の場所でプロセスに取り組む必要があります。しかし、それは「プログラミング」ではありません。

何らかの種類のテストとベンチマークを最初に配置します。

その後、何か、何かを書きます。時間切れになるか、改善できなくなるまで、refactor-rewrite -loopを実行します。

多くの人は、実際にコンピューターで何もしなくても、コンピューターで何かをすることができると考えているようですが、これは世間で最も一般的な神話の1つだと思います。建築の宇宙飛行士。

また、アルゴを書く前に最適化することはできません。

IOW、「金属の近くに滞在」。