面倒くさがりのプログラマーほど効率の良いソースコードが書けるわけ

同じ設計書を見て複数のプログラマーがプログラムを組んだとしても、仕上がりがまったく同じになるわけではありません（もちろん設計書の機能が実装されていることは前提ですが）。

ガチガチにコーディング規約を固めていれば別ですが、プログラマーの”くせ”とでも言うのでしょうか、人によって出来上がるソースコードには違いが見られます。Loop処理にしてもFor文を使う人もいれば、While文を使う人もいます。またソースコードのステップ数も人によってばらばらです。

そして今回は面倒くさがりなプログラマーほど、効率の良いプログラムが書けるという話をしていきたいと思います。

面倒くさがりは後々手が入ることを考慮したプログラムが書ける

プログラムは動けばいいやでは終わりません。バグが発生すればソースコードを追って原因個所を突き止めなければなりませんし、カスタマイズが発生すれば既存のシステムに手を入れなければなりません。そんなときにソースコードがぐちゃぐちゃでは、どこから手を付けてよいものか迷ってしまいます。だからこそプログラムは「分かりやすく・効率よく」書くことが求められます。

そして面倒くさがりなタイプのプログラマーは、後々に手が入ることを見越して、美しく効率のよいプログラムを書く努力をするのです。プログラムの構成を考える時点で、ちょっと頑張って効率化されたソースにしておけば、最終的に自分が楽できることを知っているのです。

以下に面倒くさがりが後から楽するために利用する、効率のよいプログラムの一例を記載します。

共通処理はサブルーチン化

プログラムは上から下に走っていくのが基本です。ですが全ての処理をメインモジュールに詰め込んでしまうと、ステップ数も多くなってしまい、効率の悪いプログラムとなってしまいます。

同じような処理を繰り返すような共通処理はできるだけ処理を部品化し、サブルーチンを利用することで、ステップ数を減らすことができます。ステップ数が減るだけでも、後からシステムの全容をつかむために見直す場合も楽になります。

さらに共通処理をサブルーチン化することで、その処理に変更を加えたい場合、ソースコードのあっちもこっちも修正する必要がなくなり、1個所を修正するだけで事足りてしまいます。影響範囲が少なくなり、修正後のテストのことも考えると手間も少なくなります。

例えばテキストボックスが複数あり、処理実行時に各テキストボックスが空白でないかのチェックを行う処理を実装したい場合、空白チェック処理をサブルーチン化して使い回すことで、効率の良いプログラムとなるのです。

ハードコーディングを減らす

ハードコーディングを減らすことも、面倒くさがりのプログラマーが使う手の一つ。
※ハードコーディングとはプログラムの中で使用する値などを、直接ソースの中に記載する方法。

例えば何かのタイミングで「処理が中止されました」というエラーメッセージを吐き出すプログラムを作成する場合、「処理が中止されました」という文字列をメッセージ出力の都度コーディングしていては、メッセージ内容を変更したい場合に修正箇所が増えてしまいます。

このような場合はプログラムの冒頭部で「処理が中止されました」という文字列を格納する変数を用意しておき、メッセージ出力の際にはその変数を使うようにします。こうすることでメッセージ内容に変更があった場合も、冒頭部の1箇所を修正するだけで済むのです。

 

おわりに

このように効率のよいプログラムが書けるようになると、自分自身が楽できることは言うまでもないですが、自分以外のメンバーにシステムの修正を依頼した場合にも喜ばれます。

「面倒くさがり」という言葉はあまり良いイメージではないかもしれませんが、プログラマーにとっては面倒くさがりな性格は案外大事な要素なのかもしれません。