後継者のために何を残すべきですか？

あなたが仕事を辞める唯一の開発者であると仮定します。コード自体以外のどのような情報/素材を作成し、置き換えのために残す必要がありますか？

明らかな答えは確かに「新しい仕事に望むものは何でも」ですが、私が新しい仕事を始めてからしばらく経ち、私が必要としていた最も重要なことは当時忘れていました。

考えています：

• アカウント/パスワード
• 機器、バックアップ、ソフトウェアCDの場所

ほかに何か？

• アカウントとパスワード
• サーバー情報
• 良いコード
• ドキュメンテーション
  • データベース図と説明は素晴らしい
  • コードの奇妙なリスト
• 手続き
• 手動プロセスの説明、または不定期の非自明な作業
• 彼らが使用した、または役立ったプログラムのリスト
• 連絡先 ;）

強いコーヒーと謝罪のメモ。

私が残されたことを望むものです。

• ドキュメンテーション。いくつかのコメントを書くのはどれくらい難しいですか？ビルドノート、展開ノート、システムノートの移動。再起動してすべてがなくなった場合の対処方法。
• 論文。なぜこの方法で行われているのかを書いてください。そうすれば、なぜ別の方法でそれを行っていないのか疑問に思う必要はありません。バックアップシステムの仕組み、サーバーの負荷、テスト、テストケース、ユースケースへの応答方法。
• ノート。「データベースを使用するときは、言わないでくださいSELECT * FROM clients。理由はわかりませんが、データベースをダンプします。」

私のメールアドレス、または電話番号。

私の経験では、すべての詳細を書き留めるのは難しいので、後継者がより多くの情報を必要とする場合、最良のものは（ある程度まで）利用可能であることです。

目的、将来の開発用のソースファイルの場所、パスワードなど、作成したプログラムのドキュメント。

これは、コメントとしてコード内にある場合もあれば、わかりやすい外にある場合もあります。

ドキュメントだけでなく、特定の決定が行われたときにその決定が行われた理由を知りたいと思います。現在プロジェクトでSWIGを使用しており、他の開発者の1人がBoost :: Pythonを使用しなかった理由を知りたいと思っていました。簡単な答えは、その時点で顧客がBoostの使用を許可していなかったことです。今は別の話です。

このようなことは、プロジェクトを理解するだけでなく、実装がどのような制限/制約/課題を克服するのにも役立ちます。将来のメンテナンスと機能強化のための出発点となります。

他の人が言及していなかったのは、見落としていたかもしれませんが、開発環境のセットアップ方法を文書化することです。ほとんどの場合、インストールするだけで、最新のものを入手し、コンパイルすれば完了です。ただし、それだけではない場合もあり（SharePointは頭に浮かぶ状況の1つです）、どのフラックスコンデンサーをどのように構成する必要があるかを文書化することは、後を追う貧しい人々にとって非常に役立ちます。

デスクトッププログラムの場合、システム全体をゼロから構築する方法（いくつかの別個のプログラムである場合があります）、配布用のパッケージを作成する方法（.NETのバージョンなどの依存関係）、およびサーバーに展開する方法該当する場合はダウンロードするか、CDまたはDVDに書き込みます。

Webベースのプログラムの場合、FTPおよび（該当する場合）サーバーへのSSHアクセス、およびコードをローカルで作成およびテストするために使用されるツール。

組み込みシステムの場合、バイナリイメージの構築、使用するツール、製品にコードをダウンロードしてフラッシュする方法、デバイス上のファイルシステムをセットアップする方法（ある場合）の手順を完了します。

私は最近あなたと同じような状況で仕事を辞めました（私が唯一の開発者ではありませんでしたが、実際に私たちは2人しかいなかったので、他の人が持っていなかった多くの知識を持っていますもちろん））。

通常の文書化に関しては、システム全体の概要を文書化することが重要です。個々のコンポーネントはすでにコードに文書化されていますが、コンポーネント間の相互作用と、なぜそうするのか、なぜコンポーネントと通信する必要があるのか​​が重要であり、コードをデバッグ/見るだけで簡単に理解できるとは限りません。

それから、私が去る前の約1か月間、自分にしかできないことをするたびに、何が起こったのか、何をしなければならないのか、そしてその理由を正確に書き留めました。これは通常、「xyzコンポーネントにバグがあり、それを修正するためにXのためにファイルabcを調べることがわかっていたので、これとこれとこれを行う必要がありました」というケースでした。

もちろん、自分で理解できないものが出てきた場合に備えて、メールアドレスと電話番号を残しました。最初の数週間で数回電話を受けましたが、ゆっくりと落ちました。

機能要件のリストを備えたシステムの完全なデータフロー図が必要です。そもそもシステムを書いたときには、おそらくそれを得たことはないでしょう！ほとんどの場所と同様に、最良のドキュメントはおそらくコード自体です。したがって、私が最も気に入っているのは、よくドキュメント化されたコードです。技術的にも機能的にも何をしようとしているのかを説明するコード内の行とコメント行。

ドキュメンテーションの＃1ルールは、それが行うことではなく、その理由です。実行するプログラムのバックストーリーとその機能は何ですか？

私はいつものほかにドキュメントで見たいと思うのは、どの機能が省略されたかだと思います。好きな理由、あるアイデアをしてないで実装されたり、特定のプラットフォームまたは方法はありません（そうでない場合は当然の選択だった）を使用します。

これにより、後継者は何をすべきでないかを常に知っているか、または後継者がより能力がある場合、回避策を考え出し、特定の機能を機能させることができます。

これは特にオープンソースプロジェクトに適用されます。多くの時間と脳力を節約できます！