プログラミングパラダイムとメンテナンス開発者
私は、メンテナンスのセクションがあるソフトウェアエンジニアリングの事実と誤謬を読んでいました。私は何年もメンテナンス開発者であるため、非常に興味深い事実が提示されました。これが3つです。
- 事実41：メンテナンスは通常、ソフトウェアコストの40〜80％（平均、60％）を消費します。したがって、これはおそらくソフトウェアの最も重要なライフサイクルフェーズです。
- 事実42：拡張機能はソフトウェア保守コストの約60％を占めています。エラー訂正は約17パーセントです。したがって、ソフトウェアメンテナンスは、主に古いソフトウェアに新しい機能を追加することであり、修正することではありません。
- 事実45：より良いソフトウェアエンジニアリング開発は、より多くのメンテナンスにつながります。
これは直感に反していましたが、変更が簡単なため、優れたソフトウェアの方がメンテナンスが多いことがわかりました。したがって、それはより長く使用され続け、はい、より多くの変更につながります。
どのパラダイム（機能的、オブジェクト指向、手続き型など）が最も保守性が高く、これを裏付ける研究はありますか？
機能、OO、手続き型などのパラダイムは、ソフトウェアの保守性と意味のある方法で連携しない可能性があることがわかると思います。
次のことは、ソフトウェアの保守性とより明確に一致します。
要件収集と要件エンジニアリングのレベル
優れた開発手法:(疎結合、高凝集度、単体テスト、YAGNI ...）
熟練した資格のあるソフトウェアエンジニア（彼らはモロンの10倍の価値があります）
資格のある組織化された技術QAチーム
有能なプロジェクトマネージャーが主導する優れたプロジェクト管理（熟練したソフトウェア開発者よりも見つけるのは難しいIMHO）
優れたプロダクトオーナーまたはアプリケーションマネージャー、強力なリーダーシップ、優れた長期的な方向性、プロジェクトチームへの優れたフィードバック、全体的なビジョン。
これは直感に反していましたが、変更が簡単なため、優れたソフトウェアの方がメンテナンスが多いことがわかりました。したがって、それはより長く使用され続け、はい、より多くの変更につながります。
これは、コストの割合ではなく、メンテナンスの量から見ているようです。より多くの機能が追加された優れたソフトウェアは、ソフトウェアの量が多いだけです。メンテナンスの割合が固定されている場合（これは優れたソフトウェアであり、追加機能が優れたソフトウェアとして追加されたと想定しているため）、その量は増加します。これは、同じ数のスライスを持つ大きなパイです。
あなたの質問に基づいて、「良い」ソフトウェアが関数型、OOP、または手続き型コードで書かれているかどうかが重要です。誰かにレーザー誘導パワーソーを与えると、その人が測定方法を知らない場合、木材を節約できますか？