大規模なソフトウェア会社がコードを文書化またはリファクタリングしないのは一般的ですか？
私は大手ソフトウェア会社で働き始め、100万行を超えるコードのプロジェクトに割り当てられました。これはクライアント（社内プロジェクトではなく）に販売されるプログラムスイートの一部であり、必要に応じてソースコードを購入できます（ただし、追加料金が発生することはまれです）。彼らは何年にもわたってソフトウェア設計を行っており、現在の製品は近い将来に継続することを目的としています。
驚いたことに、何百万行ものコードがほぼ完全にドキュメントに欠けています。さらに、コードの一部の領域が非常に厄介であり、理解しやすくなるようにリファクタリングを使用できる場合があります（たとえば、プログラミング言語の改善が10年ほど前に行われ、コードの大部分がはるかに多くなります）バグが発生しにくいことは言うまでもありません）。これを修正するための努力はなさそうで、私が取り組んでいる部分が抵抗に遭遇したためにそうするようにとの私の申し出は、明確な答えを得ることはできませんでした。
これらのプラクティスは、ソフトウェア業界の大企業で一般的ですか？それとも、リファクタリングやドキュメントが不足しているという点で私の会社はユニークですか？
補遺：いくつかのコメントに基づいて、私が探しているものを明確にしたいと思います。私の会社には技術的な負債があることを理解していますが、これは悪いことです。これが原因で会社が悪化しているかどうかを判断するのではなく、このドキュメントの欠如とリファクタリングへの抵抗が、私が持つプログラミングの世界での現実であるかどうかを知りたいだけです。仕事を続けたら対処する。
技術的負債の観点から、企業がプログラムを「より良く」するために投資できない理由はいくつかあります。
技術的負債を減らしても、ソフトウェアに新機能は追加されません。したがって、それは（ある程度正当な理由で）金銭的価値がないと経営陣によって認識されています。
ソフトウェアビジネスの性質は、市場に最初に与えられるものであり、最高ではありません。
私は続けることができますが、他のすべての理由はこれら2つのバリエーションにすぎません。それらはすべて、基本的に短期的な思考になり、長期的な実行可能性ではなく即時の利益に焦点を当てます。
重要なアクティブなソフトウェアプロジェクトを抱えるすべての企業には、ある程度の技術的負債があります。完全に無借金の企業はありません。
これまでに取り組んだすべてのソフトウェアプロジェクトは、時間の経過とともに技術的負債を抱えています- Jeff Atwood 。
特にドキュメントに関しては、少ないほど良いです。 1ドル1ドルの場合、ソフトウェアのドキュメントをより多く作成するよりも、ソフトウェアをより使いやすく維持しやすくすることで、より多くの利益を得ることができます。
技術的負債と、企業がそれをどのように管理するかについての非公式な調査があります。あなたがしなければならないすべてはそれらを探すことです。 これは1つです ：
または これ ：
この問題を抱えているのはあなたの会社だけではないことは明らかです。それも少数派ではないかもしれません。
（まだ）他の回答でカバーされていないと私が信じていない視点は、3つの領域での変更のコストです。
- テスト
- 再習熟
- 機会費用
大きな製品を扱う企業は、すべての変更をテストする必要があります。これらのテスト手順は、さまざまなプラットフォーム、さまざまなワークロード、さまざまな視点（パフォーマンス、機能、使いやすさ、下位互換性）で追跡する必要があります。
変更するコードの領域で作業する人も、コードに慣れる必要があります。複数のバージョンがサポートされていると、特に面倒になります（「申し訳ありませんが、どのバージョンですか？ああ、それはnewコードであり、そのためにボブと話す必要があります。同様に、単にコードを変更すると、変更ログ（差分、パッチなど）が非常に複雑になり、バグが発生した特定の時点まで問題を追跡する傾向があります。コード履歴にeverything変化する何かがある場合、非常に困難になる可能性があります。さらに、バグが長期にわたる（これらのことが発生する）場合、サポートされている複数のバージョンのコードにバグがある可能性があり、今度は非常に異なる方法で古いコードと新しいコードを修正する必要があります。
最後に、多くの場合、時間とお金をどこで使うかを決定する必要があります。これはあなたの時間以上のものですが、むしろあなたがあなたの時間でやるべきこと（そしてそれが下流のリソースに与える影響）です。より多くの売上を生み出し、新しい市場シェアを獲得し、利益を生み出すことができる機能に開発チームの時間を費やすことが望ましいのか、またはエンドユーザーが気付かないことに費やす時間/お金をかけることができないのかマーケティング資料（「ねえ、私たちの既存のコードはうんざりですが、私たちはそれを改善しました」）であり、純粋なコスト（利益なし）です。
結論、money。常に（まあ、ほとんど常に）。
はい。従業員やコンサルタントとして個人的に出会った50社ほどの企業と、同僚を通じて知り合った200社以上の企業に基づいています。
あなたが説明する種類の製品（150万行）は、構築するのに何年もかかり、多くの元の開発者は（またはマネージャーに）移行しました。
上級管理職と主要な継続顧客は、ほんの少しの変更を望んでいます。彼らは安定性を望んでいます。私たち技術者が改善と考えるのは、彼らの目のリスクです。新しいバージョンが古いバージョンと同じように動作することを示すことができたとしても、古いシステムには正確に記述された特性があり、ドキュメント化されていないため、リスクが発生します。彼らにとって、クライアントが依存する文書化されていない動作がある可能性があります。
彼らの観点から：それは壊れていないので、それを修正しないでください。また、そのための企業文化があることもわかります。あなたの「改善」に抵抗している人々は、おそらく彼らが始めたときにあなたと同じことをしたでしょう。
「勝つ」ことを期待しないでください。これは文化的な問題であり、CEOレベルでの変更以外には変更できません。