3分間プログラマ 〜その5〜。

http://d.hatena.ne.jp/zenkaifc/20081013:Title=3分間プログラマ　〜その1〜。
http://d.hatena.ne.jp/zenkaifc/20081014:Title=3分間プログラマ　〜その2〜。
http://d.hatena.ne.jp/zenkaifc/20081016:Title=3分間プログラマ　〜その3〜。
http://d.hatena.ne.jp/zenkaifc/20081017:Title=3分間プログラマ　〜その4〜。
の続き

難しいものは、意味がない。

前回、お客さんには難しいことをわかりやすく伝えろっていう、当たり前の書いた。ある意味、その続き。
会社での仕事としてコーディングをするならば、誰にでもわかりやすい、可読性の高いソースコードを書くようにしないとダメ。
これも本当に当たり前のことなんだけれども、細かいコーディング規約のない会社とか、事前に細部まで仕様を作り上げない会社なんかだと、そうでない場合がある。
コーディング全般がプログラマ個人の裁量に大きく委ねられている場合ね。結構こういう会社多いんじゃないかなぁ。

とにかく、そういう会社で、腕に自信のあるプログラマがノリにノッて書き上げた結果、複雑怪奇なソースになってしまい、さらには書いた本人にも解読不能という事態に陥ることがある。
完成した当初は、消費した工数も少ないし、機能の割にはソースの量が少ない気がする。でもなんだか複雑な気もする。

そして、そうやって完成したプログラムは、後から他の人が機能を追加しようとした場合、まずその解読に時間がかかる。
なんせ書いた本人がわからないんだから、他の人にはわかるはずがない。
そういうソースに限ってコメントがなかったり、コピペで持ってきたコメントが間違っていたりする。コメントの意味がない。
解読した結果、こちらを立てればあちらが立たず的な、絶妙なバランスの上に立っているようなプログラムであったりすると、単純な機能を追加するのにも結構苦労する。
不具合が発生した場合の修正だって同じ。
どちらにしろ、当初短縮した工数以上の工数が浪費され、結果として生産性が低下する。
いやまぁ、実際、今の現場でもそういうことが発生してるんだけどね（涙）

「この機能は難しいんだからソースの解析も難しくなって当たり前だ」
みたいな話になるんだったら、そのプログラムは会社の製品としてはふさわしくない。自分はデキると思いこんでいるプログラマの傲慢。そんなのは、会社じゃ価値がない。家でやれ。
難しい機能なので、作るのにちょっと時間はかかりました。行数も少し多いです。でも、誰が見てもわかりやすい、解析しやすいソースとコメントで構成されています。他の機能で使ったパーツもたくさん使っています。
そういうプログラムこそ、会社にも仲間たちにも、結局はお客さんにも優しい。

あなたの後輩は、あなたの書いたソースコードに容易に改造を加えることができますか？

使う人と作る人。

• システムを作る人は、使う人をナメちゃいけない。

使う人はプログラムを知らない。全体の仕様も知らない。サーバの構成だって知らない。
でも、作る人よりも、何十倍も何百倍も何千倍も業務を知っている。
業界の通例を知っている。
机上の計算じゃなくって、実際の物を知っている。
いろんな取引先のクセを知っている。
そこまで考えて、システムの要件を提示している。

システムを作る人は、使う人をナメちゃいけない。

• システムを使う人は、作る人をナメちゃいけない。

作る人は使う人の事情を知らない。全体の業務を知らない。同時に平行稼動している他のアプリケーションを知らない。
でも、使う人よりも、何十倍も何百倍も何千倍も自社の提供するシステムを知っている。
ハードウェアの構成も、そこに乗っかる環境の構成も知っている。
そして、システムの弱点、ボトルネックも実は知っている。
トリガーを仕掛けて、こっそりログを残すこともできる。
誰がどんな操作をしたのかを、みんな知っている。
そこまで知っていて、システムの提案をする。

システムを使う人は、作る人をナメちゃいけない。

結局、どっちもプロっていうことなんだけどね。

最後に。

ここまでグダグダ書いてきましたが、読んでいただいた方、本当にありがとうございました。
きっと、きっと当たり前のことだらけなんだろうけれども、自分にはこうやって文章化することで初めて気づくこともあるので、書いて良かったと思っています。

半年後に同じ会社で、いや、同じ業界で仕事をしているかどうかもわかりませんが（ポジティブな意味で）、これからもおつきあいをお願いします。
あ、だれか雇ってください（笑）