レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

プログラマーの誇りを見せ付けろ

僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。

それには理由がある。

それは、プログラマの誇りを見せたいからだ。




この案件は、既存機能をコピーして似た機能を作るというものだ。



既存機能は、Webシステムなのに1アクションで

1分や2分以上のレスポンスタイムはザラで、

悪いときには数分後にタイムアウトして、

さらに悪いときには、アプリケーション全体をロックしてしまっていた。


顧客はそれでも我慢して使っていてくれたそうだ。

今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。



それにしても酷いアリサマだとコードを見てみると

酷い。

確かにパフォーマンスは出ないのも無理はない。



いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。

この機能はそこそこ難しく、業務的にも重要だ。

しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコードだった。



例えば、

・Stringを+でツナギまくってパフォーマンスが激劣化していた。*1

SQLで、よく考えれば要らないJoinが山ほどあった。

・すべてMapで引数を取り回し、Mapの中身はすべてStringに置き換えられていた。

・数字もDateもStringだ。*2

・1000行以上もあるSQLは、適切にインデント付けされておらず、読むことすら億劫になる。

その他、Sessionの使い方、クラス分け、変数名の付け方、コメントの書き方に至るまで、

新人が試行錯誤して作った跡が見られる。


この業界の問題、それは

プログラムが、新人〜3年目の作業と位置づけられていることだ。



僕はこの認識を変えたい。

だから徹底的に、スキルの差によってどれ程のパフォーマンス差が出るか示したいと思った。*3


自慢したいわけではない、

10年近くコードと真剣に向き合ってきたから、

新人〜3年目に負けるはずはない。


このコーディングに際して、まず徹底的なリファクタリングから取り掛かった。

SQLを読みやすくインデント付けし、Mapを取りやめて適切な型のオブジェクトにし、

StringBufferをつかって、Joinを削った。

作り直したといっても良い。


もちろんチューニングは徹底的に行なった。

実装工数の三分の一を使った。 

先週まで、1アクション3秒の壁を越えられなかったけど、今日2秒を越えた。

検索自体は、0.5秒以内。改修前は、早くとも30秒だったので60倍の高速化だ。

最もパフォーマンス差が出たアクションでは、1000倍以上の差となった。


これを顧客に納品する。


今まで、1つ1つのアクションに対してイライラし続けていた機能は、

サクサクと動くようになる。

この機能は、サクサク動くと業務上の使い道が大きく広がることは間違いない。



顧客は感じてくれるだろう。

サクサク動くことの快感を。


顧客は疑問に思ってくれるだろう。

「なぜ既存機能よりも情報量の多い、この機能がこんなに早いのか?」と


そして問い合わせてくれたら良いと思う。


なぜこの機能はこんなに早くて、

他の機能はウンザリするほど遅いのかを。


そのときには、答える。

プログラミングスキルの差としか言えませんと。



新人〜3年目が悪いわけじゃない。

ベテランがコードを書かなさ過ぎる。



僕のスキル程度は、ザラに居るはず。

しかし彼らは、設計書のメッセージIDや、設計書更新日付の整合性や

フォントや罫線の切れを合わせるのに貴重な労力を割きすぎるんだ。


システム開発は、顧客の要件を実現するサービス業だ。


要件の実現がキモなのに。

実装がキモなのに。

なぜ、ベテランが頭だけやるのか。

僕にはどう考えても、理解不能だ。


今回、僕は頭の先から尻尾までやった。

それが普通であってほしい。



(追記)
前任者をけなしてるつもりはありませんです。業界の問題を感じただけで。

マネージメントやチームプレイの出来ないやつだとか、いろいろ言われるけど、
実質、予定工数から1人月前倒しで毎日定時に帰ってます。

まぁ、勢いで書いた短いエントリーで全てを伝えるのは無理なので
あとは、読者様のご想像にお任せするしかないですね。

*1:java versionは1.3です

*2:map.put("key",new Integer(100).toString())ってこと。

*3:性能改善は顧客のたっての希望があった