情けは人の為ならず～残念系コーディング～
情けは人の為ならず。
この言葉は、プログラマのためにあるのではないかと感じた。
というのは、PGさんが長期休暇に入っている今、PMと僕でシステムのメンテナンスをしているわけなんだが……ソースを開けてみた瞬間の僕の感想は。
「な、なにこれ……；」
ただ呆然。
PGさんがほぼ独りでコーディングしている部分のつくりがかなりひどいのを改めて実感させられた； ←NEさんやPMがコーディングしている部分はこんなことにはなっていない
僕ね、SQLはひよこレベルです。たまごからようやくひよこになった程度。
C#のコードに至っては1KBも書けないです。
でも、そんな僕が見てもこれはひどいと思った。
なぜなら、SQLがステートメント単位で切り出されていて、かつ、ファイルの命名規則がめちゃくちゃだったりコーディング規約が守られていないから。
すごいよ？ SQLのファイル数、１システムで400超えてたもん。
えーと具体例を挙げると……
印刷画面があるとします。
その画面のC#コードと、データ出力のためにDBからデータを取ってくるSQLは別々のファイルになるように作っています。
たとえ出力結果がほげっていても、原因がプレーンテキストで書かれているSQLなのといちいちビルドし直さなければいけないC#なのとでは現地対応のスピードがぜんぜん違ってくるからです。
外部からの持込が厳しいクライアントだと、ノートPCを持ち込んで作業ができませんし、現地にはほぼ確実にVisual Studioなんてありませんからね。
ここで、仮に不具合の原因がSQLにあるとします。
ところが、肝心のSQLファイルがいくつもあるため、いちいち複数のファイルを検索してまわらないといけないわけです。
しかも、SQLのファイル名もかなり適当で、一見して問題の画面で使われているSQLだと判別できません。
次いで、「検索しにくくなるのでむやみやたらに改行をいれてはいけない」というごく単純なコーディング規約が守られていないので、検索時に苦労します。
select文ひとつとってみても、
select * from テーブル名
と１行に書かれていれば検索時さほど困らないのに、
select
*
from
テーブル名
となっていると、検索に無駄な時間を費やします。
複数行検索はできなくもないけど、めんどくさくて時間がかかります。
１分１秒が重要な現地対応でこんなことされるとたまひよSEの僕でも、相当がっくりくるのがわかるでしょうか。
PMに至っては相当やる気をなくします。
現地対応で技術者のモチベーションが下がると結構痛いですよ。
PM「……なんでこうなっちゃうんだろう……orz」
ここで僕がすごく感じたことは、気遣いが足らないな、ということだった。
自分が現地対応するはめになったとき、この作りで大丈夫か？と思うと、こんなイミフなことにはならないと思うんだ。
迅速に対応できるエンジニアは、やっぱり先方の心象もよくなる。たとえ不具合を出してしまったとしても、現地急行即対応と何日もかかって対応とではぜんぜん評判が違う。
で、これは今すぐ対応しないとまずいという不具合が出て、いざ現地調査および対応となったとき、作りがカオスだと原因特定に無駄な時間がかかって結局持ち帰りとかになってしまうケースも少なくないorz
特にたまひよな僕は現地対応できるレベルにも限度があって、仕様やアプリの挙動から原因はこの機能のこの部分かな？まではなんとなくつきとめられても、ソースのどの部分が不具合ってるかまで特定するには相当時間を要するから、調査に時間がかかるような作りだと相当辛いのねorz
あとから自分がバグ追っかけるとき、この作りで困らないんだろうか？
現地ほど緊迫感がないから時間を気にしないのかな？
それとも、自分は現地対応しないから言われたとおりに作れば後はどうでもいいのかな！？
それってコスト意識ゼロだよね！
＃リリース前のバグに対してリリース後のバグは修正にかかるコストが100倍違うとも言われている
他にもげんなりするケースはいくつかあって、そもそもオブジェクトの制約が守られていないなど仕様が把握できてないまま作ったなってのがわかるような作りだったりとかね。
しかし先日の日記にもあるように、外注の不具合度は僕らのプロジェクトの比じゃないからな！ こんなのまだマシなのかもしれない。
かといって下を見て満足してるようじゃダメなわけで。
やっぱクオリティの高いものが作れるよう、常に意識は高い位置に持っていたいよぬ；
PMの目標とするところのひとつに「テスト担当の負担を減らそう」というのがある。
不具合が発生したらまず修正というかたちで自分のタスクが増えて、さらにもう一度テストにかけなきゃいけなくなって、その分時間もお金も消えていくわけで、それって誰も幸せにならないと思うから、まずテスト担当の負担が減るようなクオリティに持っていこうよって感じ。
これってある種の気配りに相当する部分だと、僕は思っている。
この気配りの範囲をもっと広げていくと、他人が見てもわかりやすいような作りやコードにしようとか、ちょっと考えると思いつくのではないかなと。
他人が見てもわかりやすいように作っていれば自分が原因を特定する前に現地で作業してる他の人が原因を特定してくれるかもしれない。後は直すだけ、いや場合によってはその人が修正までしてくれて、自分もハッピー！
そう考えると、情けは人の為ならずってのは、マジでプログラマ向けの言葉だと思うんだ。
IT系の仕事をしてる人の気が利かない言動を見る機会があると、その人の普段の仕事ぶりがなんとなく見えてきてしまいそうで悲しくなることがある。
僕も相当に空気が読めず女にあるまじきレベルの気が利かない人間なので、少しでも周囲に気を利かせて仕事ができる子になりたいと思う。
そのためにも、まわりの因果関係など、さまざまな視点から「考える」ことができるようになる子を目指したい。