2018年3月5日

【コンサルタント散歩】

～後々のことを考えてソースコードはコーディングしよう！～

皆さんはスクラッチ開発されたシステムの保守を担当したことはありますか。

システムの保守業務では、システムの一部に修正や変更を加えたり、機能の改善を行ったりします。例えば、システム障害が発生してソフトウェアにバグがあると想定した場合に、ソースコードを調査してバグの原因となっている箇所を突き止めようとします。その際にソースコードがごちゃごちゃして見づらく分かりにくい場合にどう思うでしょうか。ポンと頭に浮かぶのは「誰がこの〇〇ソースコードをコーディングしたんだよ！」ではないでしょうか。

特にユーザーの業務に支障をきたす障害の場合は、障害発生からユーザーへの一次報告まで時間がないことが多々あります。そういった状況でソースコードの調査を行っているとコーディングした人への恨みが増大してしまいます。では、そうならないためにソースコードをどのようにコーディングすると良いのでしょうか。筆者なりに見やすく分かりやすいソースコードは何なのか、そして見づらく分かりにくいソースコードは何なのかを考えてみました。

見やすく分かりやすいソースコード

〇 メインとなるロジックを読むことにより、機能全体の流れを把握しやすい。

〇 基本中の基本ですが、インデントがしっかりついており、繰り返しや分岐処理が一目で分かる。

〇 コメントが適切な箇所に記載されている。

〇 変数が何の用途で使われているか変数名で分かる。

〇 共通の処理がサブルーチンになっている。

見づらく分かりにくいソースコード

✕ メインとなるロジックを読んでも何の機能か分からない。

✕ 適切なインデントがされていないため、ソースコードが見づらい。

✕ 不要なコメントが多いため、ソースコードが見づらい。

✕ 変数を使いまわしており、何の用途に使っているのか分かりにくい。

✕ 同じような処理が多いため、分かりにくい。

如何でしょうか。最低限上記の内容を意識してソースコードをコーディングすることで、見づらく分かりにくいものにはならないはずです。コメントについては前回のコラム（20180115）に書かせていただきましたのでそちらを参照してください。

最後に、ソースコードは何も考えずにコーディングするのではなく、システム稼働後の保守業務や自分以外の人が調査することを前提に、見やすくて分かりやすいソースコードをコーディングするように心掛けていきましょう。

2018年3月