より大きいプロジェクトのための理想的なドキュメントセット

Question

2年前のプロジェクトで200k行のコードを使って作業する課題があれば、厄介な10のパッケージを手に入れることは十分でしょう3つのコンポーネントUML図と2ページのドキュメント？

スタートアップを合理的に早くするには理想的なドキュメントだと思いますが、時には5k行にわたる仮想化されていないプロジェクトの理解に役立つアドバイスがあります。

ありがとうございました。

Answer 1

あなたは私の同情を持っている:)私は「新しいappplicationを理解する方法」のより一般的な問題は、ソースを読むことによって、大きなコミュニティのwikiの質問

スタートになるだろうと思います。 200K回線はあまり巨大ではありません。

ソースを素早く読んでください。これはすべてを学ぶという試みではなく、重要なことが言及されている構造、アイデアのスキームなどのアイデアを得ることです。アイデアは、物事がどこにあるのかというアイデアが出てくるので、必要であると判明したときに戻ってより詳細な轍をつけることができます。

似たような状況でコードを読むときに一度尋ねられました。面白い質問だったので、答えを考えなければなりませんでした。私の場合は、アプリケーションの主要な流れと重要なデータ構造、およびそれらの管理方法と変更方法を理解することを目指します。

あなたはアプリケーションが何をするのか、それとも何をすべきかを知っていますか？それは動作しますか？それはリリースされていますか？それともまだ開発中ですか？それは造られるのだろうか？

テストスイートはありますか？そうであれば、機能のアイデアを得るためにそれらを見直してください。そうでない場合は、あなたが行った変更が間違っていると確信させるために、これらを必要とするように書き始める。

アプリケーションでは何が必要ですか？機能を追加したり、欠陥を修正したりするどちらの場合でも、「欠陥」を再現する（機能が欠けているために失敗したテストケースを書き込む。欠陥であれば、欠陥のために失敗したテストケースを書き込む）。

次に、実行中のトレースを開始して、関連するコードがどこにあるかを確認します。

よく慣れるまで繰り返します。

Answer 2

私はそれがコードがどの程度コメントされているかによって異なります。コードが自己文書化していない場合は、追加の文書が間違いなく不可欠です。一方、コードが完全にコメントされていて、関数名と変数が自明であれば、それが提供されていれば正直なところ追加のドキュメントを見ていなくても大丈夫です。

Answer 3

私はここで他のコメントをエコーし​​たいと思いますが、doxygenで直接ソースを文書化することもできます。ソースファイルのファイル構造を最初に確認してから、コメントを追加することができますアプリケーション全体のソースコードとライブラリコード。