他の誰かの過去の仕事をどのように文書化できますか？[閉まっている]

過去の従業員がビジネスクリティカルなシステムに対して行ったカスタマイズに関するドキュメントがほとんどないという悪い状況にあります。Crystal Reports、データベースエンティティ、およびERPソフトウェアの独自の構成/プログラミングファイルに多くの変更が加えられました。

現在のドキュメントは一般的に次のようなものを読みます：

このプログラムは、請求の前に実行されます。既知のバグ：なし。

ソフトウェアXのインストール後にこのプログラムを実行します。

このレポートの次のフィールドを変更しました：（方法や理由の説明なし）

私たちのITショップは小規模であり、ERPソフトウェアの場合、ほとんどの作業は1人の担当者（現在は私）に集中して行われたため、他の誰も私たちが行ったことすべてを知りません。ITと経理部門は細かい部分（たまに非常に役立つもの）を知っていますが、それだけでは十分ではありません。

もう1つの問題は、私たちの経理部門が、十分に文書化されていると考えているように見えることです。何が問題だったかについて多くの記録を残していたのは事実ですが、これらの問題を修正するために何が行われたか（もしあれば）についてはほとんど説明されていません。バグを説明する何百もの論文がありますが、変更を説明する文書（上記のように）はほとんど役に立ちません。

すべての処理がわからない場合、過去の変更を文書化するにはどうすればよいですか？私は文書化して起動することができますどのような我々が変更されました：私たちは仕事にシステムを持っている必要があるファイル、データベーステーブルECTを。私たちが何をするかを文書化することもできます。レポートが実行されるとき、なぜ人々がXレポート/プログラムを使用するように言われたか。しかし、これらのカスタマイズされたものの1つに問題がある場合、私はいつも元の状態に戻ります。

自分や他の人のために、この情報を積極的に文書化するにはどうすればよいですか？

これは無駄な運動だと思います。機能する場合は機能し、機能しない場合は修正する必要があります。

古いものを文書化する最善の方法は、それに取り組んで、何をしているかを文書化し、ビジネスロジックを説明することです（これは文書化されていなかったと思います）。これは、新しい開発者にとって大きな助けになります。

古いコード/ものを文書化するといえば、誰かがそれを所有しなければなりませんでした。これがあなたの現在のマネージャーだとしましょう。彼/彼女はそれについての完全な技術的知識を持っていないかもしれませんが、どんな変更が加えられたか知っています。その場合、それはあなたの仕事ではありません。マネージャーは、何が変更されたかについてそれについて何か書くことができます。それは歴史として保持するのに役立ちます。そのような問題が発生した場合、それらの領域を掘り下げることができ、それはあなたにとって非常に役立つかもしれません。しかし、コードに行って変更を文書化することは、かなり役に立たないIMOであり、おそらく不可能です。

変更を文書化する努力を放棄します。

代わりに、現在何がどのように機能するかを文書化してください。将来変更する場合は、そのドキュメントを最新かつ最新の状態に保ってください。

ソース管理はありますか？

それから何が変わったのか理解できますか？

その場合、新機能やバグ修正など、ビジネスの変更にマッピングできる場合があります。

古い開発者のメールボックスを復活させることは可能ですか？（これがプライバシーの問題で実行可能かどうかは不明です）。そこをトロールすることで多くの情報を得ることができます。

まず最初に。ドキュメントはどこに保存していますか？まだの場合は、wikiを設定します。私は自分自身でdokuwikiを好みますが、そうしたいのであれば、ビルド済みのvmもあります。

これはいくつかの重要な機能を提供します：

• ドキュメントには会社のLANのどこからでもアクセスできます（新しいコンピューターにインストールしています...）
• すべてのドキュメントが1か所に
• すべてのドキュメントが検索可能です
• コラボレーションできます（新しい同僚、ソフトウェアのユーザー）

さて、あなたの文書が紙の形であるなら、私はあなたに最善を祈ります。Word文書がある場合は、インポートスクリプトを作成します。

最後に、単にものを使用します。何かをインストールする必要があるときはいつでも、wikiにメモを入れてください。エッジケースにぶつかった場合は、wikiに入れてください。あなたが他の人にあなたのために仕事をしてもらうので、これはコラボレーションが輝けるところです。

より具体的なドキュメントに移り、さまざまなプロジェクトのソースを操作する必要がある場合は、適切な開発環境がセットアップされていることを確認してください。あなたが持っているべきもののチェックリストのために：

• バージョン管理（git、mercurial、fossil）
• バグ追跡（trac、mantis、redmine、fossil）
• ビルドシステム（autotools、scons、buildbot）
• プロジェクト制御（Eclipse、指定されたディレクトリー構造、エディタープラグイン）
• ソースドキュメント（README、TODO、INSTALL、ソースコメント）

最後に、ドキュメントは退屈なものになる可能性があるため、ゲームにしましょう。チェックリストの各項目に「ポイント」を与え、「スコア」を定期的にチェックします。それはあなたが何を達成したか、そしてどれだけうまくいくかを見るのに良い方法です。また、次に進む必要のある場所も示します。

これを、適切な開発環境をセットアップする方法について多くのことを学ぶ機会として見てください。そして、物事を試し、先に進むことを恐れないでください。あなたが好きなものを見つけ、環境を移行して、より良いものにしてください。最善のソリューションを構築しようとしているプロジェクトとしてこれに取り組みます。

編集：

以下のリグのコメントにあるように、ソースコードの図を作成することもできます。Freecodeにはいくつかの機能があり、この記事では人気のある言語のいくつかをリストしています。

あなたができる最善のことは、あなたが知っていることすべてを文書化し、他の人も知っていることを文書化するように会社の周りに尋ねることです。誰もが最新のドキュメントにアクセスできるように、ドキュメントをwikiまたは類似のものに集中化することをお勧めします。

知らないものを文書化することはできません。そのため、何かが行われた理由を学習して発見するか、文書化しないでください。これが、企業がまだ雇用されていることを文書化するために、より細心の注意を払う必要がある理由です。

理解できないコードを文書化しようとしている場合は、機能をテストするための単体テストを作成することをお勧めします。これにより、コードの機能を理解し、テスト自体をドキュメントとして使用できます。

幸運を！

プロジェクトまたは会社に参加していない誰かが行った何かを文書化しようとするとき、私は常に次の態度を開始します。何かを変更したり、誰かに説明したりする必要があるまで、これは私を含む全員にとってのブラックボックスです。

このプロジェクトがあなたが見つけたドキュメンテーションの形になっている理由は、あらゆる作業のドキュメンテーションは、それを実行するための副次的なものだからです。そのため、変更内容を文書化し、データベース内の特定のフィールドとコードの特定のブロックが何を実行するのかを理解した場合は、自分の利益のために他の人に利益をもたらします。

自動探索テストを作成できます。これらにはいくつかの利点があります：

• それらを書いているときにシステムがどのように機能するかを学びます

• 後で実行できるドキュメントとして機能します

• 定期的または継続的にそれらを実行する場合、変更が何かを壊したり、更新が必要になる時期を検出するための優れたセキュリティネットを提供します

特定の環境でそのようなテストを書くことが可能かどうかはわかりません。