格好つけるより、まともに動くものを！

「かっこいいソースコードより、理解しやすいソースコード」でも書いていますが、ソースコードの格好よさなど、ユーザは全く知ることができないものです。格好いいソースコードなど、単なる自己満足と言い切っても良いくらいでしょう。格好いいというのが抽象的ですが、要するに、抽象度が高くて何となく整然と書かれているように一見見えるのですが、実は誰も理解できず、結局は書いた本人すらメンテナンスができないようなソースコードのことを言っています。

プログラミングをしない人には言っていることがわからないかもしれませんが、たとえば文章と同じです。先日どなたかの記事かつぶやきにあったと思うのですが、「文章力のない人ほど難解な言葉を使う」というのと同じです。文章力がないことを隠すために、どこかから引っ張ってきた難解な言葉を使うのです。ぱっと見はすごい文章という印象を与えることができるかもしれませんが、実は誰も理解できず、そもそも読んでもらえないような文章になるわけです。プログラミングも全く同じようなものです。

ただし、困ったことにプログラミングの場合には、本当に頭が良い人も難解なソースコードを書く人が多いということもある気がします。ソースコードの抽象度を高めると言うことは、切り出しやすく汎用性も高いモジュールを作り出すことができると書いてあることが多いのですが、そのためにメモリーを食いすぎたり、可読性を下げてしまうのであれば本末転倒です。仕事でのプログラミングは自己満足のために作っているのではなく、ユーザの問題解決の為なのです。メンテナンス性の低いプログラムでは、想定外の問題が発生した場合に、関係者はもちろん、本人もさっぱり解析ができない状態に陥ります。

おまけに、そういうコードを書く人たちは、シンプルで読みやすいコードを馬鹿にする傾向がある感じもします。「こんな素人っぽい、書き殴ったようなソースは駄目だ」というような感じで。しかし、そういうソースは流れが明確に追えて、可読性が高いものが多いとも言えるわけです。もちろん、そもそものレベルが低すぎることもありますが。ビジネスプログラミングでは、凝ったプログラミングより、シンプルなプログラミングの方が多くの場合で窮地に追い込まれることが少ないものです。

このコーディングスタイルの差は、多くの場合、性格からきている気がしています。いわゆる完璧主義者は、ビジネスプログラミングにはあまり向いていないと私は考えています。凝りすぎるのと、いつまでたってもリリースしないからです。昨日書いたように、多くの物事は、やってみなければ見えてきません。時間ばかり使って個人的な完璧を求めても、多くの場合は単なる自己満足で終わるのみで、第三者が使い始めると想定外の問題がたくさん出るもので、凝りすぎて解析がなかなか進まず、ユーザをイライラさせる、というパターンがよくあります。

「まともにうごくもの！」たったこれだけがビジネスプログラミングでは欲しいのです。早く評価できて、安定してきちんと動いて、不安を感じさせず、メンテナンス性が高いプログラムが欲しいのです。早く評価できれば、時間の余裕が持てるので、仕様の問題が出ても十分改良する時間があります。メンテナンス性が高ければ改良もスムーズです。安定して動いていれば、改良を重ねても大丈夫だろうと安心できます。プログラマーの自己満足など、ユーザにはどうでも良いことです。

これからプロのプログラマーを目指す人は、是非このことを頭に入れておいてください。こういうプログラミングをしたくない人は、プロのプログラマーは目指さず、趣味で自己満足に浸っている方が幸せでしょう。プログラミングに限らず、仕事は「自己満足のためではなく、社会のため」なのですから。