技術とか戦略とか

証券レガシーシステムを8年いじってから転職した普通の文系SEによるブログ。技術のみではなく趣味の戦略考察についても。

ソフトウェアの保守性の重要性と上げる方法

ソフトウェア品質特性の一つとして、「保守性」という特性があります。
これは、ソフトウェアの修正のしやすさを示す特性であり、保守性が備わっているソフトウェアは保守開発の際に低コスト・高品質で開発することが可能になります。
品質の高いシステムを開発するために、ソフトウェア開発を行う技術者は、成果物(書き上がったソースコード)の保守性を高めることを心がける必要があります。
 
【保守性を高める重要性】
システムは一度作って終わりではなく、バグ対応や機能追加、外部環境の変化(法改正や連携システム改修等)への対応で繰り返し保守開発を行います。基幹システムでは、20年30年に渡って保守開発を続けることも珍しくありません。
保守性が低いソフトウェア、具体的に言えば読みにくいソースコードや影響調査が困難なソースコード、改修の影響が広範囲に広がってしまうソースコード(設計)を書いてしまうと、保守開発の際に新たなバグを埋め込むリスクが高くなり、品質を保つことが難しくなります。品質を保とうとすると、事前の影響調査やテストに多くの工数を費やすことになってしまいます。
低コスト・高品質の保守開発を実現するためには、保守性の高いソフトウェアを開発する必要があります。現存しているソフトウェアの保守性が低い場合は、保守性を高めるためのソースコード改変(リファクタリング)の検討も必要になります。
 
【保守性を高める具体的な方法】
保守性を高めるには、以下のような方法があります。
 
1.可読性の高いコーディングを心がける
 これはどのようなシステム・言語でも意識する必要がありますし、
 新人でも意識する必要があります。
 具体的には「わかりやすい命名にする」「似たようなコードを増やさない」等で、
 以下のページに詳しく書かれています。
 
 初心者が保守性の高いプログラムを書くために注意するべきこと プログラミング教室情報サイト【プロナビ】
 https://programming-study.com/trouble/things-to-keep-in-mind-when-writing-programs/

 
 付け加えるとするなら、現場のコーディング規約に従うことが重要になります。
 特に、命名規則は現場毎で独自のルールがあることが多く、
 英語かローマ字かを指定されたり、アンダーバーの有無を指定されたり、
 良く出る単語の一覧が書かれていたりします。
 命名規則を無視すると、たとえそのソースコード単独では読みやすくても、
 調査が困難になるので注意が必要です。
 (例えば、元号改正の対応を行う場合、
  ルール上では「元号」を"era"とすべき所"gengou"とされてしまうと、
  検索で"era"と探した時に検索結果から漏れてしまいます)
 
2.変更に強い設計を心がける
 これは設計者になってから意識することですが、
 設計によって変更に伴う影響箇所を限定しやすく(変更に強く)なります。
 大まかな思想としては「プロセス中心アプローチ」
 「データ中心アプローチ」「オブジェクト指向アプローチ」
 と呼ばれるものがあり、当ブログでも以下の記事で紹介しています。
 
 https://akira2kun.hatenablog.com/entry/2018/11/28/232857

 
 また、オブジェクト指向に関しては、
 デザインパターンの考え方を取り入れることで、
 変更に強い設計とすることができます。
 当ブログでも以下の記事で紹介しています。
 
 https://akira2kun.hatenablog.com/entry/2018/09/24/160550
 
 更に、SpringFramework等のフレームワークを取り入れることで、
 低コストで変更に強い設計・コーディングを行うことができます。
 
3.変更に強いプロセスモデルを取り入れる
 具体的に言えば、エクストリームプログラミング(XP)の考え方が有効です。
 例えば、以下のような考え方が提唱されています。
 
 ・テスト駆動開発
  機能の実装よりも先に自動化されたテストコード(JUnit等)を作成する。
  機能の実装はテストコードを通過するように行う。
  
 ・ペアプログラミング
  コーディングを行う人とコーディングを見る人の2人でコーディングを行う。
  コーディングしたその瞬間にレビューが行われる、
  ソースコードが共有されることでその後の保守体制を組みやすくなる、
  等の効果を得られる。
 
 ・YAGNI(You Ain't Gonna Need It)
  先の保守開発を予見して複雑な実装とするのではなく、
  今必要な機能のみをシンプルに実装することで、
  後の予測困難な改修に対応しやすくする。