見やすいだけではない？保守性がいいソースとは

Romiは数千万の日本語データを学習しミクシィが独自に開発した人工知能を搭載。見た目がとてもキュート！Romiを家族に迎えよう！

保守性とは

保守性が高いというと、下記の要点を押さえているソースと言える。

具体的に保守性が高いとどのようなときにメリットになるかを紹介したいが、その前に保守の人がどのような仕事をしているかを紹介する。

保守の仕事は何か

現場によって様々であると思うが、保守の仕事は大きく以下の３点が挙げられる。

本番定常作業

定常作業は、決められた作業手順に従い、日々本番環境の監視を行う作業。
具体的には、本番のパフォーマンス測定（データ量の増加に伴いメモリやハードディスクの増設の検討をするため）や、特定データの監視（将来インシデントになり得るデータを監視する）作業を行う。
保守にとって一番コスパが高い作業。決められた作業手順通りに作業すればよいので、ノーリスクハイリターンな仕事。

インシデント対応

一番心臓に悪い仕事。
本番アラートが発令すると、それの原因調査、リカバリ対応、再発防止を考えねばならない。
原因の調査の仕方としては、

やはりこのインシデント対応にて、保守性が高いソースというのは活きてくる。

効率化活動

普段実施している作業をいかに楽に実施できるかを考え、改善していく活動。
例えば本番定常作業で行っている作業を自動化し、日々の負担を減らす等を考えたり、
リカバリ不要の本番アラートを鳴らなくして、原因の確認の作業を減らしたり等を行う。

保守が一番苦労する点

保守が一番苦労する点はやはり、インシデント対応でしょう。
よくわからないアラートのログを解読し、よくわからない機能のソースを見て、原因を調べ、リカバリ方法を考えなくてはいけない。。
非常に胃が痛くなる作業。
この作業を楽にこなせられるソースが保守性が高いソースと思う。

保守性がいいソースとは

見やすいソース（可読性が高いソース）

見やすいソースを作るためには以下の点を押さえられれば問題ない
・Input項目とOutput項目が明確になっているか。そしてそれらを取得、編集する処理がまとめられているか。
・変数名と使用目的が一致しているか
・適切にコメントを記載しているか（複雑な処理などは特に）
・インデントは正しいか（IF文がどこまで繋がっているかを理解しやすくするため）

修正しやすいソース（拡張性が高いソース）

修正しやすいソースとは、一番影響が少なく修正できるソースと言える
・不要なソースからの呼び出しがされていないか
・増減しうる項目の場合、プロパティファイル等に定義し、修正の負担を軽減する
・その機能の目的を明確にし、不要な処理を入れない。

ログ出力設計が適切（インシデント対応がしやすいソース）

ログは、アラートが発生した際に最初に見る情報のため、この時点で大方の情報を把握できれば、その後のインシデント対応が容易になる。
・いつ、どこで、だれが、何をしたかを把握できるようなログ出力になっているか。
これを押さえていれば問題ない。
バッチのログ出力の場合、
いつ：YYYY/MM/DD HH/MM/SSSSSS
どこで：どのバッチ機能で
だれが：特定のデータか、処理対象のデータ全体か
何をしたか：どういったエラーがでたか（データの不正エラーか、必須チェックエラーか）

まとめ

保守の人を意識しなくても物は作れるが、リリース後の運用が本当の本番であると思うので、
保守の人たちの仕事を考えながら開発を行えば、より保守性の高い、より品質の高い成果物ができると思います。