企業にレガシーソフトウェアの文書化を始めるよう説得する方法
入社してから1年も経っていない。彼らの売上の大部分は、過去10年以来生き残っている単一の製品から来ています。ただし、ドキュメントは最小限（あるとしても）です。
社内の開発者はドキュメントの不足に苦しんでいるだけでなく、売上高が高く、全員が時間を無駄にしています。これは、経験豊富な開発者が退職し、コミュニケーションやブレインストームを行うためのリソースがますます少なくなっているためです。
詳細についてはあまり触れずに、製品の概要を説明するある種のドキュメント（少なくともアーキテクチャドキュメント）が必要であることを前のマネージャーに提案しました。 JavaDoc およびその他の自動ドキュメントツールの使用も提案しました。これらの提案は、微笑みと「十分な時間がない」、「今すぐ短期的な改善が必要」、さらにはプログラマー自身からの「コード自体がドキュメントであるべき」などの声明で応えられました。
要件/バグごとに必要なものがこの大きな（実際の）コードベースに存在するかどうかを確認するために、十分な時間を費やしてすでに無駄になっています。ドキュメンテーションの必要性に関してあなたが与えるかもしれないあらゆる提案を探しています。または、むしろ、これがこのレガシーシステムまたは組織にとって失われたケースである場合。
あなたの痛みが分かります。私は以前にこの正確な位置にいたことがあります。
私の提案は、模範を示すことです。 Wikiやドキュメントを作成し、メモを書き始めます。まとめるこのドキュメントを繰り返し参照します。誰かがあなたに質問をした場合は、最初に回答を探すためにドキュメントを見て見せてください。質問がない場合は、未回答の質問のセクションに追加してください。成長するにつれて、みんなと共有してください。文書化する時間をメンテナンスタスクに追加します。
これを有機的に育てる必要があります。チャンピオンが必要です。私は、ドキュメントを気にしない会社が突然その切り替えを反転させる、開発者主導の議論を知りません。それが整ったら、誰もがそれなしでどうやって成功したのか不思議に思うでしょう。悲しいことに、あなたが先に進むと、それはおそらく時代遅れになり、死ぬでしょう。
これらの種類のお店は働くのが恐ろしいです。死んでいる負傷した動物と同じように、私は彼らに同情します。
古い技術、技術的な負債で溢れ、絶えず火を消し、ますます不満が増し、怒り、時にはベンダーロックされた顧客基盤...おなじみの音ですか？
ストレスがたまっているマネージャーから得られるほんのわずかな笑顔は、彼が毎日処理しなければならない混乱のために、おそらく平均余命が短いことを知っていますか？それは、会社に新しいプログラマーを10年近く雇って、まったく同じことを言ってきた人の笑顔です。売上高がすべて同じであるにもかかわらず、同じ結論に達した他の開発者が少なくともほんの一握りではなかったことを少しの間考えないでください。
彼らは物事をより良いものに変えることに失敗し、欲求不満になり、他の人のように去ったので、彼らはもうそこにはいません。しかし、必ず自分でこれを行うようにしてください。私たちは成功からではなく、失敗から最も多くを学ぶ傾向があります。
彼らは自分たちが負った傷の泥沼に苦しんでいて、最終的に顧客が道を見つけたとき、またはこの場所にもっと良い競争相手がやってきたとき、もうそこにはいません。
もし私があなただったら、探し始めます。このようなソフトウェアショップにはもう我慢できません。
ドキュメンテーションのプッシュ（これは重要です）の他に、テストの作成をプッシュすることもお勧めします（テストがまだ行われておらず、行っていない場合は、喜んでテストします）。 Michael C. Feathersが彼の本で述べているように レガシーコードで効果的に作業する 、テストはレガシーアプリケーションで雑然としたコードを処理する良い方法です。コードの特定の部分がどのように機能するかを理解するのに役立つテストを記述します。これは、コードの理解を深めるために、アプリケーションのアーキテクチャを文書化するのに役立ち、必要なリファクタリングにも役立ちます。
幸運を！あなたの痛みも感じます。
あなたはおそらく、彼らがあなたのポストで高い離職率を持っている理由の核心を持っています。あなたはすでに管理に関する懸念を提起しました。文書化のビジネス上の理由を指摘して正式な方法で行ったことを確認してください（サポートコストの削減とコードを理解するためのリソースの浪費）。
懸念を正しい方法で提起しても、経営陣がそれを無視する場合は、選択はa）それを吸い上げるb）新しい仕事を探す（私はbをお勧めします）
someのドキュメントを作成するのに上司の許可が本当に必要だとは思わない。ドキュメントを開始する最も明白な場所はコードです。
ドキュメントのみの攻撃を開始する必要はありません。日常業務の一部としてドキュメントを組み込むことに集中してください。 JavaDocコメントのないメソッドで作業する場合は、コメントを追加します。複雑であるが必要なものを追加する場合は、いくつかのコメントを追加して説明します。そしてもちろん、追加するすべてのnewコードまたは機能が完全に文書化されていることを確認してください。
既に取り組んでいるコードに対してこれを行うことは、特定のタスクに数分以上追加することはなく、コードの全体的な品質が徐々に向上します。