ケース2の対応法：コーディングルールの策定
ケース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つ例をあげて説明しました。次回は、監視を切り口とした内容を説明します。
- 障害対応を考えて開発しましょう
- 障害の原因究明に備え、例外処理の記述ルールを策定しておきましょう
- バグ修正に備え、コーディングルールを策定しておきましょう
この記事をシェアしてください
バックナンバー
この記事の筆者
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
