大規模なコードベースを学ぶボランティア開発者へのアドバイス
オープンソースプロジェクトで作業すると、コードベースの経験がない開発者が自分で「コードを学ぶ」ことを試みることがあります。
私が見た繰り返しの罠があり、新しい開発者は次のことを試みます。
何かを行う前にすべてを理解してください。
これらは、自分のプロジェクトにのみ取り組んだ開発者、または少なくともこれがうまくいく可能性のある小さなコードベースである傾向があります。
私の印象では、彼らはコードを本のように少し読み込もうとし、終わり近くのどこかで "ahah"の瞬間があることを望んでいます。彼らはそれを理解し、新しいコードを書き始め、生産的になります。
（ここでは少し簡略化しています）。
これはいつもひどく終わっているようです。
彼らは、彼らのアプローチに疑問を呈するのではなく、コードが混乱していて、より多くのコメントが必要であると不平を言っています。
（コメントを含めるかどうかは大きなトピックです。議論の目的で、コードは適度にコメントされていると想定できます。）
コードが完璧であることを示唆するわけではありませんが、一部の開発者はなんとかそれを学び、生産的になります。
私にとって、アプローチはそもそも欠陥がありますが、これはそのような一般的な仮定/間違いであるため、尋ねます。
開発者がすでにコードを読んで大規模なコードベースを入力しようとして失敗した場合：
提案するためのより良い代替アプローチは何ですか？
「オープンソースのボランティア」の側面に関する注記（説明のために追加）
このトピックへの返信で、ボランティアに関する部分は重要ではなく、大規模なコードベースのanyの新しい開発者がこれらの問題に遭遇することが出てきました。
これは場合によっては当てはまるかもしれませんが、ボランティアが組織に雇用されていないという違いがあります。ボランティアは好きなことを好きなように行うことができます。また、ガイダンスを求めずに自分でかなりの量の作業を行うことができます。さらに、彼らもすべてのアドバイスを無視することができます。 たとえば、彼らの仕事が拒否されたとしても、彼らはそれを開発し続けたり、フォークを始めたりするかもしれません...。
これは通常、クローズドソースソフトウェアで作業するために開発者が採用した場合ではありません。
大規模でなじみのないコードベースに飛び込んだ私の経験から、重要なことは、プログラムがどのように分割されているかを理解し、次に焦点を合わせるだけだと思いますあなたが変更している部分に。これは、私が毎日作業しているコードベースにも、これまでに見たことのないコードベースにも当てはまります。
プログラムが適切に設計されている場合、モジュール/コンポーネント/ピース/何でもそれらの間に明確な境界があり、互いの動作に対する明確なブラックボックスの期待があります。これにより、詳細がほとんどまたはまったくなくても、モジュール内での作業が非常に簡単になります。他の人の知識。疑わしい設計のプログラムでさえ、通常have十分なモジュール化がありますが、モジュール間の境界がどこにあるかを明確にできないだけです（通常は「過剰結合」と呼ばれるものを介して）。なんらかの奇妙な理由で、プログラムがどのように構成されているかを新しい人に伝えることができない場合、彼はmain（）を確認するか、デバッガーで物事をステップスルーすることで、非常にゆっくりとプログラムをつなぎ合わせることができます。 1つの関数またはクラス。
新しい開発者は、「何かをする前にすべてを理解する」必要があるという本能は実際には真実です単一のモジュール内。比較的新しい人にとって、適切な「モジュール」は、1つのクラスを実装する単一の.cppファイルである場合もあれば、ブラックマジックをスケジュールするスレッドプールを実装する5〜10個のファイルである場合もあります。コードベース全体に精通している人が本当に必要いくつかのモジュールに影響を与えるのは「横断的変更」だけです。
編集：オープンソースプロジェクトのボランティアは、従業員が通常行うようなチュートリアルやウォークスルーを取得できないため、ideasman42は「ボランティア」らしさが問題に関連していることを明確にしました。それに対して、私はこう言います：それがかなりまともなオープンソースプロジェクトである場合、コードがどのように構造化されているか（およびその理由）それはその特定の方法で構成されています）。 Githubのようなプラットフォームでは、これは非常に簡単です。
この回答の元のバージョンを書いた後（以下の注釈を参照）、新しい開発者に存在する精神的なギャップを分析する代わりに、最も重要なことを調査する必要があることに気付きました。新しい開発者が精神的なギャップを埋めるために行う必要があること。これが私の主張です。
この状況で新しい開発者ができる最善のことは、このソフトウェアが提供する必要のあるすべての機能の使用に関する包括的なトレーニングを受けることです。
新しい開発者がコードを理解する上で明らかな妥当性を持っていないと仮定すると、その人は他にどのような不十分さを持っている可能性がありますか？新しい開発者に欠けているのはユーザーの視点です。
別の言い方をすれば。新しい開発者が何らかの形で「ライブラリ内の特定のコードを実行させる」必要があるとします。何があっても。開発者はどのようにそれを行いますか？ アプリケーションでこれを実行するには、内部でこれとそのコードをトリガーします。
これは、かなりの数の主要なソフトウェア企業における最新のオンボーディング原則です。実際、「トレンディな」業界のWebサイトを読んでいる人なら誰でも、このアプローチについて言及しているはずです。それについて注目に値する、または独創的なものは何もありません。それはただの知恵です。
ボーナス：類推
頭の上の釘を打つのを助けるために、これは1つです：
小説を書くことをどのように学びますか？辞書を覚えることから始めますか？
ソースコードを読んで完全に理解しようとすることは、辞書を使って語彙を学ぶようなものです。しかし、新しく学んだ語彙を実際に使用しなければ、意味と定義はおそらくあなたにとってほとんど意味がなく、それらの単語のあなたのコマンドはすぐに消えてしまいます。
真に何かを学ぶためには、人々の使い方に応じて、さまざまな視点から学ぶ必要があります。
それほどではありませんが、テスト環境でライブラリから取り出した単一のモジュール化されたコードを実行できることもおまけです。これは、新しい開発者がそのコードがどのように実行されるかについての理解を確認するのに役立ちます。
このニーズは、ユニットテストスイートを用意することで部分的に満たされます。ただし、新しい開発者には、本番用コードと新規コードの両方をテストするための「厄介な実験環境」も必要になることを指摘しておく必要があります。したがって、新しい開発者は通常両方を必要とします。
以下は、以前の回答（現在は非推奨）です。参照用にここに保管してください。
全体像
この問題について議論するときは、オープンソースライブラリのアマチュア使用と本番使用を区別する必要があります。
プログラマーユーザーが雇われるか、支払われるか、収益を上げるかどうかに違いはありません。
違いは次のとおりです。プログラマーユーザーが、ライブラリが何十または何百もの異なるユースケースであることをよく知っているかどうか現在対応可能です。
問題は、プログラマーユーザーが認識を欠いている場合、提供されたコードの変更は、処理が不十分であるために拒否される可能性が非常に高いことです。
コードの変更が原因で発生した単一のユースケースの失敗は、「回帰」と呼ばれます。
これは落胆させるものですが、学習を思いとどまらせたり止めたりする合図と見なされるべきではありません。学習曲線を受け入れて、押す必要があります。
ローカルスコープまたはモジュール式の変更に貢献する機会
場合によっては、オープンソースライブラリでローカルスコープの改善点を特定できることがあります。作業するために前述の幅広い認識を必要としないほど十分に小さい。
一部のライブラリは、新しい機能をエレガントに「ボルトオン」できるように（アーキテクチャ的に）設計されている場合があります。その機能が品質の問題に屈した場合、そのメンテナがそれを取り除くのは簡単です。
これらの機会があれば、新しいプログラマーが貢献することが可能になります。
そのような機会を特定することは簡単な作業ではありません。時には、メンテナの専門家がそれを行う必要があります。
たとえば、Google Summer of Code（GSoC）、および他の企業や組織からの同様の取り組みの全体的な前提は、そのような機会を特定するためのメンター（メンテナーの専門家メンバー）の軍隊と、スポンサー（Google）は、メンターと教育の新人プログラマの両方に協力して協力するための払い戻しを行います。
「弾丸追跡」イベントが原因で発生する機会
この状況は、実際にはオープンソースライブラリの商用利用で最も一般的です。
ソフトウェア会社は、オープンソースライブラリを生産目的で利用します（収益を生み出すもの、または会社や組織の日常業務に必要なもの）。
ある日、プログラマーがライブラリーの欠陥を特定しました。プログラマーは業界で専門的な知識を持っており、そのライブラリーを日常的に使用しているため、そのライブラリーで知識を獲得しています。
プログラマーは、欠陥の根本原因を特定し、そのための許容可能なコード修正を考え出すために、（時間、賃金などのお金、テクニカルサポートの連絡先、およびバグ追跡データベースの検索に関して）多大な努力を払います。
現在、この集中的な共同作業により、プログラマーは、ライブラリの機能やユースケースの他の無関係な側面を十分に認識していなくても、このオープンソースライブラリに貢献できる可能性があります。
したがって、これは冒頭で述べた全体ビューの例外です。
「手持ち」、「オンボーディング」、および新しい開発者をスピードアップできるその他のアクティビティ。
手持ちとは、プロジェクトメンターが、図書館やアプリケーションドメインにまったく慣れていないプログラミング担当者に、辛抱強く（時には処方したり、スプーンで餌をやったり）赤ちゃんのステップを与えることを指します。
オンボーディングとは、次のことを前提として、誰かにライブラリの組織概要を提供することを指します。
- その人はアプリケーションドメインについてある程度の知識があり、自分の努力でそれをさらに学ぶことができる
- その人はソフトウェアアーキテクチャについてある程度の知識を持っており、それについてさらに学ぶことができます。
- その人はすでに優れたプログラミングスキルを持っており、その面で手を握る必要はありません。
- その人は毎日その図書館を利用するので、学習の進歩は速いと予想されます。
商用設定では、「オンボーディング」の対象となるプログラマーのみがソフトウェアプロジェクトへの参加を検討されます。 「手持ち」を必要とするプログラマーには、チャンスが与えられることは決してありません。
警告：ほとんどのライブラリの開発者向けドキュメントは、適切なオンボーディング用に書かれていますが、手持ち用ではありません。
handholdingドキュメントの例は次のとおりです。
- OpenCVチュートリアル
- HIPR2-画像処理学習リソース 、
これはソフトウェアライブラリではなく、教育資料です。
比較可能なライブラリのonboardingドキュメントと比較してください。
現実には、国のSTEMイニシアチブの一環としてライブラリがSTEM教育で目立つように取り上げられていない限り、多くの本や初心者向けチュートリアルが開発される可能性はほとんどありません。
同様のことが言えるのは、MATLAB、R、Octaveなどです（MATLABはプロプライエタリソフトウェアパッケージであるため、オープンソースの貢献の機会はありません）。
Doctrine（ソフトウェアプロジェクトの編成）、およびindoctrination。
traditionalオープンソースライブラリ（1990年代以前にルーツを始めたもの）は、ハンドホールドやオンボーディングを使用していないようです。代わりに、彼らはライブラリが何をすべきかを述べた信頼できる文書を維持しています。
私はこれを教化と呼んでいます。ライブラリコードもメンテナも完璧ではありません。しかし、教義によれば、すべてが完璧に向かって進んでいます。
オープンソースライブラリ「doctrines」の例：
これは冗談めかして「RTFM」（*）と呼ばれますが、数百ページのドキュメントの中で、ほとんどのオープンソースライブラリには1つの目立つように機能する誤りのページがあります。パッケージのルートでは、単に"README"（ファイル拡張子なし）と呼ばれることもあります。これはそのライブラリのdoctrineです。
これは、ライブラリの多くの「仕様」または「動作契約」を指定します。
（注）良識があるとしましょうRTFMは「創設者の原稿を読む」の頭字語です。
最後の無関係な暴言-大学はそれほど重要ではないと言った他のオンラインの人々へ。
上記のすべてをなんとか読み通せば、適切な大学教育の経済的重要性が明らかになるはずです。
それは、新卒者が機会、期間のために手持ちを必要とすることから救います。
そうでなければ、新卒者は最初の就職先を見つけるのに苦労するでしょう。
必須の免責事項：上記の企業に直接雇用されていません。