システムの運用・保守を考えていますか？第1回

ケース2の対応法：コーディングルールの策定

ケース2は、プログラムのコーディングルールが決まってないことが原因です。大規模プロジェクトになればなるほど、このような事例は起こります。開発時は50人がソースコードを書いていたのに、保守は1人というケースも十分にありえますし、1人で50通りの書き方を把握するのは酷というものです。

そのためにも、開発を始める前に、コーディングルールを策定しましょう。幸い、コーディングルールに関しては、2004年に電通国際情報サービスが「Java コーディング規約2004」を公開するなど、参考事例が数多くあります。詳細はこちらの記事「Javaコーディング規約」をご覧ください。

この中で、おろそかになりがちなルールにポイントを絞って説明します。それは「コメント」です。コーディングルールには、「どの程度までコメントを記述すれば良いのか？」という話に関しては「わかる程度」と曖昧なことが多いので、あらかじめプロジェクトごとに検討する必要があります。システムによって、プログラムの難易度は変わるので、具体的な基準を決められないためです。

基準の決め方の一例となりますが、コメントは詳細設計書の1部を抜粋するのはどうでしょうか。見出しを記載するだけでも十分に効果があると思います。

リスト3：詳細設計書の見出しを記載したコメント例

//1-1-1：リクエストから情報S1、S2を取得

	

	String S1 = request.getAttribute(“S1”) ;

	String S2 = request.getAttribute(“S2”) ;

	

	//1-1-2：情報S1、S2の入力チェック

	checkZipCode(S1);

	checkAddress(S2);

開発時、プログラマは常に「読んでわかるか」を考えながら記述するのも大変ですから、コメント記述が機械的にできれば作業負担を減らすことができます。また、運用・保守担当者は詳細設計書をみながら、バグ修正を進めることがあります。ソースコード中に詳細設計書の見出しがあると、内容の把握が早く、バグ修正がよりスムーズに進みます。

今回のまとめ

障害対応を考え、開発時に考慮すべきポイントを、2つ例をあげて説明しました。次回は、監視を切り口とした内容を説明します。

障害対応を考えて開発しましょう

障害の原因究明に備え、例外処理の記述ルールを策定しておきましょう
バグ修正に備え、コーディングルールを策定しておきましょう

表5：今回のまとめ

この記事をシェアしてください

障害発生を考えていますか？

バックナンバー

この記事の筆者

老川正志

みずほ情報総研株式会社

技術企画部システムエンジニア
2001年、株式会社富士総合研究所（現みずほ情報総研株式会社）入社。システム開発部門への技術支援業務を経験後、データセンターソリューション「TEXIV（テキシブ）」の立ち上げに参画、2002年から現職。現在は、ホスティングサービス事業の拡大のほか、システム開発効率向上の企画・調査を担当。

老川正志のプロフィールを見る