ソフトウェアを書くのは、最初から読んで理解するよりも簡単ですか？[閉まっている]

私と私の友人は、昨日、大規模なC ++ソフトウェアを書くことと、それを新規採用者として理解することとの違いについて話し合っていました。

ソフトウェアは一度に1行ずつ実行され、このプロセスは私たち（人間）が物事を学び、別の物の上に物事を構築する方法に似ているので、大きなソフトウェアを書くことは実際にそれを読んでそれが何をするかを理解するよりも簡単です（コードをステップスルーすると役立ちますが、複数のクラス/ソースファイルを一緒に覚えておく必要があります。それらが何のために書かれているのかさえ知らない、マルチスレッドコードは悪意のあるポイントを追加します）？

これは最初は奇妙に聞こえますが、少し考えた後、合理的であるように見えました

私の経験に基づいて、次のアクティビティを最も簡単なものから最も困難なものの順にランク付けします。

1. 良いコードを読む
2. 悪いコードを書く
3. 良いコードを書く
4. 悪いコードを読む

上記のランキングは2つの結論につながります

1. 悪いコードを読むよりもコードを書く方が簡単ですが、独自のコードを書くよりも良いコードを読む方が簡単です
2. 悪いコードを書くことは良いコードを書くよりも簡単ですが、悪いコードを書くことは悪いコードを読むための準備をします。これはすべての中で最も難しいことです。特に、悪いコードは書かれているよりも多く読み取られるためです。

もちろん、良いコードと悪いコードは広く一般化されています。良いコードの詳細については、コードの完成とクリーンコードをお勧めします。

この質問は、誤ったコンセンサスに訴えます。http://en.wikipedia.org/wiki/False-consensus_effect

異なる人々は異なる方法で情報を学び、吸収します。聴覚学習者、視覚学習者、運動学習者に似ています。コードを読むのが簡単な人もいれば、コードを作成するのが簡単な人もいます。私にとっては後者です。私のチームの他の人にとっては、前者です。ある種のコンセンサスや多数派を見つけることが有用だとは思わない。脳が情報をどのように吸収して学習するかを理解し、その知識を使って自分自身を改善し、異なる人を受け入れることを学ぶのがよいでしょう。

大規模なC ++ソフトウェアの作成と新規採用者としての理解の違い

これは、ソフトウェアの読み取りと書き込みの違いと同じではありません。プロジェクトを初めて使用するとき（特に会社を初めて使用するとき）、コードが何をするのかだけでなく、学ぶべきことがたくさんあります。理解する理由コードが、それは多くの場合、ビジネスのプロジェクトは、組織の残りの部分とどのように関連するか、どのように動作を理解する必要がないものを行います。要するに、背景知識の恩恵なしにコードを読むことは、コードが機能するコンテキストを完全に理解しているとき、コードを読むことよりも遅くて難しい作業です。

グリーンフィールドプロジェクトで新しいコードを作成することと、既存のコードを読み取り、変更することには違いがありますが、必ずしも一方が他方よりも簡単であるとは言いません。新しいものを作成する場合、既存のコードを使用してコードを機能させる方法を心配する必要はありませんが、プロジェクトが将来も有用であるように十分に拡張可能かつ適応可能にすることを心配する必要があります。既存のプロジェクトで作業している場合、多くの場合、すでに存在するものをガイドとして使用できますが、最初に存在するものを理解する必要があります。

「新人」として、通常、既存のプロジェクトで作業する方が良いでしょう。なぜなら、ビジネスの仕組み、さまざまなプロジェクトがどのように連携するか、標準と実践のコーディング、さらには（特に）改善できるもの。

興味深い質問ですが、作成するよりも読みやすく、理解しやすいという側面に傾く傾向があります。

ベテランでベテランのプログラマーなら、コードを読んで「はい、良い選択、チェック、ああ、YではなくXを行ったかもしれません」などに進む可能性があります。ゼロからの書き込みよりも膨大な時間を節約します（そうする理由がない限り）。

あなたがより新しいプログラマである場合、「あなたが知らないことを知らない」ので、あなたはすべてのささいなことを発明/学習しなければならず、おそらくあなたはいくつかの非効率性を持つことになりますコード。ただし、言語の理解が深まる可能性があります。

ただし、どちらの場合でも、コードを完全にゼロから作成するよりも、コードを読み取ってそこから移動する方が簡単です。

ほとんどのプログラマーは、他の人が書いたコードと比較して、自分で書いたコードを理解しやすいと感じています。これは、あなたが言及した行ごとの学習だけでなく、個々のスタイルと才能の問題によるものです。そんなに多くの車輪の再発明が起こる理由です。

しかし、それは木の眺めです。フォレストビューでは、コードを最初から記述するよりもコードを読む方がはるかに簡単です。たとえば、新しいワードプロセッサをゼロから作成したり、既存のコードベースを十分に学習して改善するのは簡単ですか？

コードの読み取りを開始すると、コードを読みやすくするための膨大な方法を考えることができます。コードをたどるだけで、土地のレイアウトを把握しようとするときに、最初に時間を費やします。アーキテクチャーでは、その方法を完全に嫌うこともあります。しかし、実際に大規模なコードベースであっても、そのアプリケーションの作成にすでに数十万時間を費やしているのに比べて、ホイールを回転させるのに40〜80時間かかります。

ソフトウェアの一部を書いている人は、ほとんどの場合、プログラムを書いている間にロジックとその思考プロセスを知っているだけで、プログラムを最もよく理解します。

コードを書くことは、コードを読むことと理解しやすさの点でまったく比較できるとは思いません。一方では、単にソフトウェアを書くだけで、コードの各セクション、使用されるライブラリなどに関連するコンテキストの知識により、特定のソフトウェアをより深く理解できます。ただし、他の人が書いたコードを読むことは、実際のソフトウェアですが、言語を理解するという点では、使用を検討していなかったライブラリの新しい方法や使用法についての洞察を提供することができます。これにより、コードの記述が簡単になります。

ビルドの知識に関しては、コードの読み取りとコードの記述は非常に関連性があり、多くの点で相互に関係していると思います。コードの記述経験は、他のコードの理解を容易にし、コードの読み取りにより、（新しいロジックの概念、ライブラリの使用などを通じて）コードを簡単に書くことができます。

これは私が個人的に自明であると感じたものですが、プログラミングの大衆全体に当てはまることを完全に確信したことはありませんでした。たとえば、ドキュメントを読むのではなく、他の人のコードを喜んで選択し、自分のコードのように理解できる非常に才能のあるコーダーを知っています。

これは質問につながります：これは重要ですか？

コードを読んでいる場合、書き換えるのではなく変更を行っている可能性があります。書き換えている場合でも、新しい言語/バージョンでこれを書いている可能性が高いため、必ずしも同じ方法でコードを作成できるとは限りません。私が言いたいのは、常にすべてのコードを理解する必要はないということです。

これはすべて真実であり、BDDなどの新しい開発方法論は、単にマシンを駆動する手段であるコードではなく、ビジネスロジックをコードから明確にすることが重要であることを認識しています。もちろん、これは新しいものではありません。コンセプトは、ドナルドクヌースの独創的な研究：Literate Programming以来です。

私はStMotorSparkの答えに興味を持っています。ただ追加するだけです。
それは多くの要因に依存しているので、イエスかノーの質問にはなりえません。

• 既存のコードは適切に文書化され、適切に作成されていますか、それとも意味やコメントのないスパゲッティのように見えますか？
• 解決方法を見つけるのに無限の時間を費やす非常にまれな状況の小さなアプリですか、それとも大きくてシンプルなアプリですか？
• 等