ソフトウェアを書くことは、一から読んで理解するよりも簡単ですか？
私と私の友人は昨日、大規模なC++ソフトウェアの作成と新入社員としての理解の違いについて話していました。
ソフトウェアは一度に1行ずつ完了し、このプロセスは私たち（人間）が物事を学び、その上に物事を構築する方法に似ているため、大きなソフトウェアを書く方が実際に読んで理解するよりも簡単である可能性はありますか（コードをステップ実行すると役立ちますが、複数のクラス/ソースファイルを一緒に覚えておく必要があります。それらが何のために書かれているかさえわからないので、マルチスレッドコードは悪意のあるポイントを追加します）？
これは最初は奇妙に聞こえますが、少し考えた後、それは合理的に思えました
私の経験に基づいて、次のアクティビティを最も簡単なものから最も難しいものの順にランク付けします。
- 良いコードを読む
- 悪いコードを書く
- 良いコードを書く
- 悪いコードを読む
上記のランキングは2つの結論につながります
- 悪いコードを読むよりもコードを書く方が簡単ですが、独自のコードを書くよりも良いコードを読む方が簡単です
- 悪いコードを書くことは良いコードを書くよりも簡単ですが、悪いコードを書くことは悪いコードを読むように設定します。これはすべての中で最も難しいことです。特に悪いコードは書かれている以上に読み込まれるからです。
もちろん、良いコードと悪いコードは広い一般化です。優れたコードの詳細については、Code CompleteおよびClean Codeをお勧めします。
この質問は、誤ったコンセンサスに訴えます。 http://en.wikipedia.org/wiki/False-consensus_effect
人によって情報の学習と吸収は異なります。聴覚学習者、視覚学習者、運動学学習者に似ています。コードの読み取りが簡単な人もいれば、コードの作成が簡単な人もいます。私にとっては後者です。私のチームの他の人にとっては、前者です。何らかのコンセンサスや過半数を見つけることは役に立たないと思います。脳がどのように情報を吸収して学習するかを理解し、その知識を利用して自分をより良くし、異なる人を受け入れることを学ぶのが良いでしょう。
大規模なC++ソフトウェアの作成と新規採用者としての理解の違い
これは、ソフトウェアの読み取りと書き込みの違いと同じではありません。プロジェクトが初めての場合（特に、会社が初めての場合）は、コードの機能だけでなく、学ぶべきことがたくさんあります。 理由を理解するには、コードが何を行うかを理解するには、ビジネスの仕組みやプロジェクトが組織の他の部分とどのように関連しているかを理解する必要があります。つまり、背景知識を利用せずにコードを読み取ることは、コードが機能するコンテキストを完全に理解している場合に、コードを読み取るよりも遅く、困難な作業です。
greenfieldプロジェクト での新しいコードの作成と既存のコードの読み取りと変更の違いはisですが、私はそうしません片方は必然的にもう片方よりも簡単であると言い、ただ違うだけです。新しいものを作成するときは、コードを既存のものと連携させる方法について心配する必要はありませんが、プロジェクトを十分に拡張性と適応性を持たせて将来にわたって役立つようにすることについて心配する必要があります。 。既存のプロジェクトで作業しているときは、すでに存在するものをガイドとして使用することがよくありますが、最初にそこにあるものを理解する必要があります。
「新入社員」としては、ビジネスの仕組み、さまざまなプロジェクトがどのように連携するか、コーディングの標準と実践、さらには、 （特に）何を改善できるか。
興味深い質問ですが、作成するよりも読みやすく、理解しやすいという側面に傾く傾向があります。
あなたがベテランでベテランのプログラマーなら、コードを読んで「うん、良い選択、チェック、ああ、私はYの代わりにXをやったかもしれない」などになるかもしれません。ゼロからの書き込みにかかる時間を大幅に節約します（そうする理由がない限り）。
あなたがより新しいプログラマーなら、「あなたはあなたが知らないことを知らない」ので、あなたはすべての小さなことを発明/学習しなければならず、おそらくあなたはいくつかの非効率性を持っているでしょうコード。ただし、言語の理解を深めることができます。
ただし、どちらの場合でも、コードを最初から完全に書き込むよりも、コードを読んでそこから移動する方が簡単です。
ほとんどのプログラマーは、自分が書いたコードを他の人が書いたコードよりも理解しやすいと感じています。これは、あなたが述べた行ごとの学習と、個々のスタイルと才能の問題の両方によるものです。だからこそ、ホイールの再発明がたくさん起こります。
しかし、それは木の見方です。フォレストビューは、コードを最初から書き込むよりもコードを読み取る方がはるかに簡単であるということです。たとえば、新しいワードプロセッサを最初から作成する方が簡単ですか、または既存のコードベースを十分に改善して改善する方が簡単ですか。
コードを読み始めると、コードを読みやすくするための無数の方法を考えることができます。最初にコードをトレースしながら、土地のレイアウトを理解しようと試みます。時々、アーキテクチャーでは、それを実行したい方法に完全に反対しています。しかし、本当に大規模なコードベースであっても、アプリケーションの作成にすでに費やされた数十万人時間と比較して、ホイールの回転に40〜80時間を費やすことになります。
ソフトウェアを書いている人は、ほとんどの場合、プログラムを書いている間のロジックと彼/彼女の思考プロセスを知っているだけで、プログラムを最もよく理解できます。
理解しやすさという点では、コードを書くこととコードを読むことを比較することはまったくできないと思います。一方では、ソフトウェアを作成するだけで、コードの各セクションに関連するコンテキスト、使用されるライブラリなどの知識により、その特定のソフトウェアについての理解が深まります。ただし、他の人が作成したコードの読み取りは、実際のソフトウェアの一部ですが、言語を理解するという観点からは、使用していないと思われるライブラリの新しい方法や使用方法についての洞察が得られ、コードを簡単に作成できるようになります。
ビルドの知識に関しては、コードの読み取りとコードの書き込みは非常に関連があり、多くの点で相互にビルドされていると思います。コードの作成経験により、他のコードの理解が容易になり、コードの読み取りにより、コードの作成がより簡単になります（新しいロジックの概念、ライブラリの使用などを通じて）。
これは個人的に自明であると私が感じたものですが、それがプログラミングの大衆全体に当てはまることを完全に確信することはできませんでした。たとえば、ドキュメンテーションを読むのではなく、他の人のコードを喜んで選び抜いて、まるで自分のコードのように理解できる、非常に才能のあるプログラマーをいくつか知っています。
これは質問につながります：これは問題ですか？
コードを読んでいる場合は、コードを書き換えるのではなく、変更を加えている可能性があります。書き換えている場合でも、新しい言語/バージョンでこれを書く可能性が高いため、必ずしも同じ方法でコードを作成する必要はありません。私が指摘している点は、常にすべてのコードを理解する必要はないということです。
これらすべてが真実であり、新しい開発方法論、たとえば [〜＃〜] bdd [〜＃〜] コードが単にマシンを駆動する手段ではなく、コードからビジネスロジックを明確にすることが重要であることを認識しています。もちろん、これは新しいことではありません。この概念は、ドナルドクヌースの独創的な研究 Literate Programming 以来存在しています。
StMotorSparkの答えに興味があります。
これは、はいまたはいいえの質問にはならないほど多くの要因に依存します。たとえば、
- 既存のコードは十分に文書化され、適切に記述されていますか、それともセンスやコメントのないスパゲッティのように見えますか？
- 解決策を見つけるのに無限の時間がかかる非常にまれな状況の小さなアプリですか、それとも、大きくてシンプルなアプリですか？
- 等.