私は最近、その一部を開発する複雑な組み込みプロジェクトチームの一員になりました。私の責任である部分については、古いコードのみがあり、多くのドキュメントはありません。
私は良いスタートを切ることに熱心ですが、恥ずかしがり屋で愚かに見えることへの恐れが質問をするのを難しくしています。質問する方法は？
プロジェクトを理解するためにあなたたちがどのようなテクニックを使っているのか聞きたかったのですが？つまり、デザインを作成するために覚えておく必要のある技術的な詳細がたくさんあるということです。あなたはコードを読んでいくつかの事実を入手しますが、どのように先に進むのですか？たとえば、コードとドキュメントを読んで、いくつかのファクトAとファクトBを取得します。事実CとDも考慮する必要があるかもしれないし、そうでないかもしれない適切な結論Xに到達する方法は？
十分なドキュメントがなく、コードのドキュメント化や記述が不十分な場合、コードの読み取りは特に困難になる可能性があります。今の最善の方法は、コードのエントリポイントを見つけて、そのフローと使用するデータをゆっくりと理解することだと思います。気をつけて
構造-エンティティ/システムのパーティション化はありますか？コードのどこで（そしてどのように）それらは互いに通信しますか？
データ-グローバルデータを保持するためにどのような構造が使用されていますか？データはどのようにアクセスおよび保存されますか？
CまたはC++を実行している場合は、メモリがどのように処理されるかを確認することも重要です。C++（およびその他の関連する非管理メモリOOP言語）の場合、オブジェクトの所有権はどのように含まれるかを確認することも重要です。
組み込みプロジェクトなので、非標準のコードやコーディング構造が使用されていますか？
私の経験では、バグ修正やその他の小さな変更など、ある種のタスクから始めるのが最善です。それはあなたの学習に焦点を当てます。バインダーを読んだり、ソースコードやドキュメントのページをふるいにかけたりするのは、それを適用する方法がないと難しいと思います。
コードベースを台無しにすることなく行った変更を試すことができるサンドボックスがある場合、それはさらに役立つ可能性があります。
コードを読むことは、ドキュメントを書くことによってバランスが取れています。
交換に必要なドキュメントを作成します。あなたよりも知識が少ない人を想像してみてください。その人のためにそれを説明してください。
交換品に何か説明できない場合は、質問してください。
完全な説明があれば、システムを「知る」ことができます。
そして、あなたは完全なドキュメントを作成しているでしょう。
どんな種類のテストが存在するかについては言及していません。テストケースがある場合は、それらを変更して、これが最終結果にどのように影響するかを追跡します。
たとえば、OOPシステムのクラス図を見ると非常に役立つなど、システムの論理構造の全体像を示す図を確認することをお勧めします。大規模で複雑なアプリの設計図を見ると、システムの内部モジュールがどのように構成されているかが明確に理解できます。これにより、特定のコードがどの機能を実行するかを理解する作業がはるかに簡単になります。ダイアグラムがない場合は、main（）のようにアプリのエントリポイントから開始し、システムに関する独自の結論を描画（文字通り描画または紙に書き留める）しながらそこから進むのが最善の策です（このようにして、独自のドキュメントを作成できます）、同僚に正しいかどうかを尋ねます。