大規模なソフトウェア会社がコードを文書化またはリファクタリングしないのは一般的ですか？[閉まっている]

私は大規模なソフトウェア会社で働き始め、100万行を超えるコードのプロジェクトに割り当てられました。これはクライアント（社内プロジェクトではなく）に販売されるプログラムスイートの一部であり、必要に応じてソースコードを購入できます（ただし、それに関連する追加料金が発生することはまれです）。彼らは何年にもわたってソフトウェア設計を行っており、現在の製品は近い将来に継続することを目的としています。

驚いたことに、何百万行ものコードがドキュメントにほぼ完全に欠けています。さらに、コードの一部の領域は非常に厄介であり、理解しやすくなるようにリファクタリングを使用できる場合があります（たとえば、プログラミング言語の改善が10年ほど前に行われ、コードの大部分が大幅に増加します）バグが発生しにくいことは言うまでもありません）。これを修正するための努力はなさそうで、私が取り組んでいる部分が抵抗に遭遇したためにそうするようにとの私の申し出は、明確な答えを得ることはできませんでした。

これらのプラクティスは、ソフトウェア業界の大企業で一般的ですか？それとも、リファクタリングやドキュメントが不足しているという点で私の会社はユニークですか？

補遺：いくつかのコメントに基づいて、私が探しているものを明確にしたいと思います。私の会社には技術的な負債があることを理解していますが、これは悪いことです。これが原因で私の会社が悪化しているかどうかを判断するのではなく、このドキュメントの欠如とリファクタリングへの抵抗が、私が持つプログラミングの世界での現実であるかどうかを知りたいだけです。私がそれで働き続けるならば対処するために。

技術的な負債の観点から、企業がプログラムを「より良く」するために投資できない理由はいくつかあります。

1. 技術的負債を減らしても、ソフトウェアに新機能は追加されません。したがって、それは（ある程度正当な理由で）金銭的価値がないと経営陣によって認識されています。

2. ソフトウェアビジネスの性質は、市場に最初に与えられるものであり、最高ではありません。

私は続けることができますが、他のすべての理由はこれら2つのバリエーションにすぎません。それらはすべて、基本的に短期的な思考になり、長期的な実行可能性ではなく即時の利益に焦点を当てます。

重要なソフトウェアプロジェクトを抱えているすべての企業には、ある程度の技術的負債があります。完全に無借金の会社はありません。

私が今までに働いてきたすべてのソフトウェアプロジェクトは、時間をかけて技術的負債を計上しているが - ジェフ・アトウッドを。

特にドキュメントに関しては、少ないほど良いです。1ドル1ドル。ソフトウェアのドキュメントをより多く作成するよりも、ソフトウェアをより使いやすく維持しやすくすることで、より多くの利益を得ることができます。

技術的負債、および企業がそれをどのように管理するかについて、いくつかの非公式な調査があります。あなたがしなければならないすべてはそれらを探すことです。 ここに一つあります：

またはこれ：

この問題を抱えているのはあなたの会社だけではないことは明らかです。それも少数派ではないかもしれません。

さらに読書
技術的負債を管理する上で第3回国際ワークショップ-概要
ソフトウェアリライアントシステムで管理する技術的負債

他の回答で（まだ）カバーされていないと私が信じていない視点は、3つの領域での変更のコストです。

1. テスト
2. 再習熟
3. 機会費用

大きな製品を扱う企業は、すべての変更をテストする必要があります。これらのテスト手順は、さまざまなプラットフォーム、さまざまなワークロード、さまざまな視点（パフォーマンス、機能、使いやすさ、下位互換性）で追跡する必要があります。

変更するコードの領域で作業する人も、コードに慣れる必要があります。複数のバージョンがサポートされていると、特に面倒になります（「申し訳ありませんが、どのバージョンですか？ああ、それが新しいです。コードとそのためにボブと話す必要があります」）。同様に、単にコードを変更すると、変更ログ（差分、パッチなど）などが非常に複雑になり、バグが発生した特定の時点まで問題を追跡できます。すべてを変更するコード履歴に何かがある場合、非常に困難になる可能性があります。さらに、バグが長期にわたる（これらのことが発生する）場合、サポートされている複数のバージョンのコードにバグがある可能性があり、今度は非常に異なる方法で古いコードと新しいコードを修正する必要があります。

最後に、多くの場合、時間とお金をどこで使うかを決定する必要があります。これはあなたの時間以上のものですが、むしろあなたがあなたの時間でやるべきこと（そしてそれが下流のリソースに与える影響）です。より多くの売上を生み出し、新しい市場シェアを獲得し、利益を生み出すことができる機能に開発チームの時間を費やすことが望ましいのか、またはエンドユーザーが気付かないことに費やす時間/お金をかけることができないのかマーケティング資料（「ねえ、私たちの既存のコードはうんざりですが、私たちはそれをより良くしました」）であり、純粋なコスト（利益なし）です。

結論として、お金。常に（まあ、ほとんど常に）。

はい。私が従業員またはコンサルタントとして個人的に遭遇した50ほどの企業と、同僚を介して知っている200以上の企業に基づいています。

あなたが説明する種類の製品（150万行）は、構築するのに何年もかかり、多くの元の開発者は（またはマネージャーに）移行しました。

上級管理職と主要な継続顧客は、ほんの少しの変化を望んでいます。彼らは安定性を求めています。私たち技術者が改善だと考えるのは、彼らの目のリスクです。新しいバージョンが古いバージョンと同じように動作することを示すことができたとしても、古いシステムには正確に記述された特性があり、ドキュメント化されていないため、リスクが発生します。彼らにとって、クライアントが依存する文書化されていない動作があるかもしれません。

彼らの観点から：それは壊れていませんので、それを修正しないでください。また、そのための企業文化があることもわかります。あなたの「改善」に抵抗している人々は、彼らが始まったとき、おそらくあなたと同じことをしたでしょう。

「勝つ」ことを期待しないでください。これは文化的な問題であり、CEOレベルでの変更以外には変更できません。