プログラミングパラダイムとメンテナンス開発者[終了]

私が読んでいたのは、保守のセクションがあるソフトウェアエンジニアリングの事実と誤りです。私は何年もの間メンテナンス開発者でしたので、私は非常に興味深い事実を提示されました。3つあります。

• 事実41：メンテナンスは通常、ソフトウェアコストの40〜80％（平均、60％）を消費します。したがって、それはおそらくソフトウェアの最も重要なライフサイクルフェーズです。
• 事実42：拡張機能は、ソフトウェア保守コストの約60％を占めています。エラー訂正は約17％です。したがって、ソフトウェアのメンテナンスは、主に古いソフトウェアに新しい機能を追加することであり、修正することではありません。
• 事実45：より優れたソフトウェアエンジニアリング開発は、より多くではなくより多くのメンテナンスにつながります。

これは直観に反するものでしたが、変更が簡単なため、優れたソフトウェアのメンテナンスが多いことがわかります。したがって、それはより長く使用され続け、はい、より多くの変更をもたらします。

どのパラダイム（関数型、オブジェクト指向、手続き型など）が保守性が最もよく、これを裏付ける研究はありますか？

機能、オブジェクト指向、手続きなどのパラダイムは、ソフトウェアの保守性と意味のある方法で相互に関連付けられていない可能性があります。

次の内容は、ソフトウェアの保守性とより明確に関連しています。

• 要件収集と要件エンジニアリングのレベル

• 適切な開発手法：（疎結合、高凝集、単体テスト、YAGNI ...）

• 熟練した資格のあるソフトウェアエンジニア（彼らはバカの10倍の価値があります）

• 認定および組織化されたテクニカルQAチーム

• 有能なプロジェクトマネージャーが率いる優れたプロジェクト管理（熟練したソフトウェア開発者IMHOよりも見つけるのが難しい）

• 優れたプロダクトオーナーまたはアプリケーションマネージャー、強力なリーダーシップ、優れた長期的な方向性、プロジェクトチームへの優れたフィードバック、全体的なビジョン。

これは直観に反するものでしたが、変更が簡単なため、優れたソフトウェアのメンテナンスが多いことがわかります。したがって、それはより長く使用され続け、はい、より多くの変更をもたらします。

コストの割合ではなく、メンテナンスの量からこれを表示しているようです。より多くの機能が追加された優れたソフトウェアは、より多くのソフトウェアです。メンテナンスパーセンテージが固定されている場合（それが優れたソフトウェアであり、追加機能が優れたソフトウェアとして追加されたと想定しているため）、量は増加します。これは、スライスの数が同じ、より大きなパイです。

あなたの質問に基づいて、「良い」ソフトウェアが機能的、OOP、または手続き型コードで書かれたかどうかが重要です。人が測定する方法を知らない場合、誰かにレーザーガイド付きのパワーソーを与えて木材を節約できますか？