保守性には細かく言うと、機能拡張性や性能・規模拡張性、デバッグやチューニングの容易性などが挙げられると思うのですが、私がこれまで経験した現場においては、これらの項目はシステム設計やモジュール・階層設計、データ構造設計、基底・抽象クラス設計、デバッグ機構やシステムパラメタ設計等々といった設計フェーズ、いわゆる上流工程で主に議論・吟味され、「ソースコード以外」のドキュメント上にて完結されることがほとんどでした。
コードそのものに向けられる観点といえばせいぜいコーディング規約やコメントくらいで、上流工程のそれに比べてあまりにも貧弱であり、そういう意味では保守性を考える際に、
”ソースコードだけに目がいきやすい”
というのは実際の現場においてはあまりないのではないか、というのが私の認識です。少なくとも保守性が「属人的な指標」であるというのは言い過ぎではないかと思います。なぜならデバッグロギング機構の有無のようなところでソフトウェアの保守性を語ることができるからです。
可読性を議論する際に注意が必要なのは、その論点がコーディングスタイルだけに限定されがちで、これをもって「属人的な指標」と言われてしまうことです。これは可読性のメリットの多くが拡張性や保守性とセットになることが原因で、例えばMVCモデルのようなアーキテクチャはコードの可読性向上に大きく貢献しましたが、拡張性のメリットの影に隠れてあまり語られることがないように思えます。
またリファクタリングの目的の大半が可読性向上による保守性の維持であり、例えば冗長なロジックの最適化やクラス・関数構造の見直し、共通モジュール化といった修正がほどこされますが、このような修正がはたして「属人的な指標」と言えるのでしょうか。
プログラマの教育は多くの現場で可読性の領域までなされることはなく、個々人の独学に委ねられています。プログラミングスキルが水準に達していないプログラマは、グローバル変数の乱用や複雑な条件分岐など一般的に見て悪いコードと評価できるくらい可読性の低いコードを量産します。一番の問題はこうしたコードが現場において公に問題視され議論されないことで、これを引き継いだ担当者は修正の複雑さやリファクタリングにかかるコストを一人で背負わされている現状があると思います。また可読性の低いコードを作った本人のスキルがいつまで経っても向上しないというのも問題で、基礎教育の観点においても議論が必要なのではと感じています。
気難しいプログラマ
「ソースコードの質」
https://el.jibun.atmarkit.co.jp/genmaicha/2010/11/post-5c3e.html
地方からの戯言
「ソースコードの可読性や保守性」
https://el.jibun.atmarkit.co.jp/ahf/2010/11/post-e035.html
参考： 分かりやすいコード
参考： ソースコードの低可読性の問題認識
参考： SI業界の理想と現実
参考： 上流・下流の分離構造は諸悪の根源か？
参考： 下流工程の質
コメント