Contents
なぜ、保守性が高いと良いのか?
新規開発時はあまり意識しないかもしれないです、保守フェーズや性能テストフェーズなどから参画した場合、誰かが書いたコードを変更していくことになります。
その時に、保守性の低いプログラムは、まずどこに何が書いてあるかわかりません。
さらに、影響範囲が広すぎて、変更後のテストをやりたくなくなります。
保守性の高いソースコードは、問題箇所・変更すべき箇所の特定が容易で、影響範囲が限定的です。
ソフトウェアの生涯からすれば、新規開発よりも保守運用の時間の方がずっと長くなるため、保守性が高い=変更しやすいプログラムにしておくことが重要です。
新規開発よりも、保守フェーズは人員が少ないため、少ない人員でも日々の変更要求をさばけるように、保守性を高めておくことが大事です。
保守性が低いと、要因を増員したり、修正を先延ばしにする必要が出てくるため。コストがかかります。コストがかかると、企業の儲けを減らしたり、他の分野に投資することができなくなるため、よくありません。
変更しやすい=保守性が高いソースコード群とは?
変更しやすいソースコードからなるソフトウェアの特徴を挙げます。
1.問題箇所・変更箇所の特定が容易である
まず、保守性が高いソースコードは、変更すべき箇所、指摘されている現象を起こしている箇所の特定が簡単です。
逆に問題箇所の特定が難しい or 時間がかかる場合、プログラムを修正しようという気がなくなること、影響範囲を明確にすることを諦めやすいという弊害を生みます。
プログラムを修正しようという気がなくなると、明らかに無駄なことをしている処理だったとしても、他の修正手段に逃げることになってしまいます。
これは、ソースコード群がシンプルな構造になっていないことから引き起こされます。最上位から数えて5階層以上のような深い場所にあると、
保守性の高いソースコードの前提、MVC
まず、シンプルなMVCになっていることが可読性向上に繋がります。
このために、コントローラーはXxxControllerというクラス名、ModelにあたるServiceにはYyyServiceという名前がついてると、保守担当は一目見ただけでクラス構成を掴めるようになります。
古いシステムでEJBが採用されてる場合、どれがコントローラーでどれが業務ロジックなのがわからず、解読に苦労することになります。
保守性を高めるために取り入れたいこと
コードを分割する
コードを分割することはとても重要です。1つのメソッドが100行を超えてくると、可読性が下がるので、分割するようにします。
また、クラスについても、「これは何のクラスなのか?」が一言で説明できないとダメです。
自動テスト(JUnit)
JUnitが適切に組まれていることで、間違いなく、変更に対する安全性が高まります。
影響範囲を気にせずソースコードを変更できたら、どれだけ快適でしょうか。一切気にせず変更を加えることはないと思いますが、
シンプルなアーキテクチャになっていて、適切なコンポーネント単位に分割されていて、適切なコメントが書かれていて、適切にJUnitが組まれているソースコード群が、良いと言えます。