見づらいプログラムは禍根を残す!? (2008年06月16日)
突然ですがプログラミングは好きですか?
プログラミングする際、少し難しくても効率の良いAPIを使ったり、オブジェクト指向言語を利用している場合に効率化のためにパターンなどを積極的に取り入れてプログラムを作ったり・・・なんていうことは、ありませんか?私もプログラミングは好きですし、(であるが故に)以前はよく、そういうプログラミングをしていました。
でも、一度自分が作ったプログラムを見直してみてください。
そのプログラム見やすいですか?
例えば、他の人が開発したアプリケーションの拡張や修正をしなければならない場合で、設計書など仕様を把握できるものがほとんど無く、プログラムを解析する以外に仕様が確認できないというような状況を経験したことはありませんか?
私は何度もそういった状況で、必死にプログラムとにらめっこした経験があります。
そういう時、冒頭に書いたようなプログラムだと作った人間以外には難しく感じてしまい、プログラム解析に時間がかかって対応が遅れたり、対応したとしても実は見落としがあって修正した以外の箇所で障害を発生させてしまう・・・といったことが多々あります
対応するのが熟練プログラマーの場合はそれでもなんとかなるかもしれませんが、経験の浅いプログラマーの場合にはどうなるでしょうか?分析に手間取り、いつまでたっても対応が出来ない・・・なんてことも、平気でありえます。
作った本人にとっては見やすく効率の良いプログラムかもしれませんが、他の人にとっては難しいだけの見づらいプログラムになってしまっているかもしれません。
自分はそんなことはしない!と思っている人(こそ)は、下記をチェックしてみてください
・IF分岐などの条件文が長すぎる
・プログラム中のコメントがなさ過ぎる、もしくは細かく書きすぎている
・プログラム(クラス)の分割を細かくやりすぎている
・Javaなどオブジェクト指向言語の場合に、積極的にインターフェースや継承を使っている
・難しく実装していて、一見すると効率よくみえるが、よく見ると非常に単純かつ簡単に実装ができる
これは私の今までの経験から、見づらいと感じたプログラムに共通したことです。
思い当たるところはありませんか?
プログラマーとして熟練してくると、効率よく簡素に作ろうとして逆に難しく考えすぎてしまうことがよくあります。
プログラムは作ったら終わりではなく、その後何年も使われ続けるものです。難しいプログラムは保守性が下がり、その後何年も苦しむ元凶(?)の元になります。特に、保守担当が新人の場合は、その悲劇たるや想像するだけで悲惨なものあがります。
プログラミングをする時は誰が見てもわかりやすい物を作る!という(当たり前のようで、意外に実践されていない)意識を、プログラマーは持たなければいけないのではないでしょうか。
林田宏介

コメントする