保守性の高いソースコードの作り方

Contents

なぜ、保守性が高いと良いのか？

　新規開発時はあまり意識しないかもしれないです、保守フェーズや性能テストフェーズなどから参画した場合、誰かが書いたコードを変更していくことになります。

その時に、保守性の低いプログラムは、まずどこに何が書いてあるかわかりません。

さらに、影響範囲が広すぎて、変更後のテストをやりたくなくなります。

保守性の高いソースコードは、問題箇所・変更すべき箇所の特定が容易で、影響範囲が限定的です。

　ソフトウェアの生涯からすれば、新規開発よりも保守運用の時間の方がずっと長くなるため、保守性が高い=変更しやすいプログラムにしておくことが重要です。

新規開発よりも、保守フェーズは人員が少ないため、少ない人員でも日々の変更要求をさばけるように、保守性を高めておくことが大事です。

保守性が低いと、要因を増員したり、修正を先延ばしにする必要が出てくるため。コストがかかります。コストがかかると、企業の儲けを減らしたり、他の分野に投資することができなくなるため、よくありません。

変更しやすいソースコードからなるソフトウェアの特徴を挙げます。

　まず、保守性が高いソースコードは、変更すべき箇所、指摘されている現象を起こしている箇所の特定が簡単です。

逆に問題箇所の特定が難しい or 時間がかかる場合、プログラムを修正しようという気がなくなること、影響範囲を明確にすることを諦めやすいという弊害を生みます。

プログラムを修正しようという気がなくなると、明らかに無駄なことをしている処理だったとしても、他の修正手段に逃げることになってしまいます。

　これは、ソースコード群がシンプルな構造になっていないことから引き起こされます。最上位から数えて5階層以上のような深い場所にあると、

まず、シンプルなMVCになっていることが可読性向上に繋がります。

このために、コントローラーはXxxControllerというクラス名、ModelにあたるServiceにはYyyServiceという名前がついてると、保守担当は一目見ただけでクラス構成を掴めるようになります。

古いシステムでEJBが採用されてる場合、どれがコントローラーでどれが業務ロジックなのがわからず、解読に苦労することになります。

コードを分割することはとても重要です。１つのメソッドが100行を超えてくると、可読性が下がるので、分割するようにします。

また、クラスについても、「これは何のクラスなのか？」が一言で説明できないとダメです。

JUnitが適切に組まれていることで、間違いなく、変更に対する安全性が高まります。

影響範囲を気にせずソースコードを変更できたら、どれだけ快適でしょうか。一切気にせず変更を加えることはないと思いますが、

シンプルなアーキテクチャになっていて、適切なコンポーネント単位に分割されていて、適切なコメントが書かれていて、適切にJUnitが組まれているソースコード群が、良いと言えます。