下限に合わせたプログラム設計はシステム開発を停滞させる

FxUG@北陸の懇親会で出た話題。

中規模以上のプロジェクトになれば、悲しいかな、テンプレにそったプログラムしか書けない人や、そもそもプログラムを書いたことすらない人が結構いたりします。10人もかき集めれば2〜3人、いや半分はそういう人だったり。リーダーさんは仕様検討とかで忙しいから、そういう初級者さんにプログラムの作成を頼らざるを得ないってのが現実です。

で、初心者さんにもわかりやすい設計のプログラムを量産していきましょう、となる現場はよくあります。なに、うちのところもそんなもんですよ。

でもそれで良いの？と、個人的には疑問を持っています。

• 初心者でも書けるように、テンプレートをコピーして使う。
  • コピペ駆動開発の副作用は周知の通り。
  • テンプレートが役立つのは限定的な場合。仕様が想定の範囲を超えればテンプレートを捨てなきゃならないけど、その判断を誰が下す？
• 後々の保守しやすいよう、初心者でも読みやすいプログラムにする。
  • モジュール化されていないコードがばらまかれてる時点で、本当に保守しやすくなってる？
• 誰でも書けるように、詳細な設計書を用意する。
  • 誰が書いても詳細な設計書を作らなきゃならないってどうよ。コード書けば1日で終わるのに、設計書も書けば2日。さらに、いつの間にかコードと設計書の整合性が取れてなくて、確認で2日追加とか。
    • DRYって何？

人海戦術に忙しく、初心者はテンプレートのコピーしか出来ず、上級者は初心者がコピーするテンプレートの作成しか出来なくなる。技術の習得や業務知識の獲得なんてあったもんじゃない。この「下限にあわせたプログラム設計」を認めるということは、チームの技術力向上をあきらめ、初心者は初心者でしかないっていうヒエラルキーを固定化してしまう危険がある。初心者はこのレベルしか出来ない、期待するな…と言いつつ、そのレベルしか出来ないって決め付けてるんじゃないの？って。

個人的な経験で言えば、「より良いプログラムを書いてほしい」と伝えれば、メンバーの半数は期待に応えてくれたんですよ。

元々器用だった人もいたし、「継承って何？」って人がある程度デザインパターンを使えるようになったりとか。曖昧なオーダで「とりあえず動くもの」を作るのが早い人もいたし、それをシンプルなクラス構造に落とすのが得意になった人もいた。反面、どうにも不器用な人もいたし、「テンプレからプログラムを作るのが自分の仕事だ」みたいに落ち着いたオッサンとかもいたし、設計がCOBOLから止まってる人もいたし。そう考えると、ベテランさんの方が期待に応えてくれなかったことが多いような気もする。

何より、自分も証人の一人っていう自信はある。3年前にJavaでstaticと非staticの違いすらわからなかった人が、一応それっぽいコードを書けるようになった、という相対的な上達の割合という意味で。

どうせ人海戦術なんて破綻する運命にあるし、言語や設計手法の習得コストなんて計算に入ってないし、いつだって派遣会社は「優秀な技術者です！」と言うし（すいません、派遣会社だけじゃないですw）、設計検討やリファクタリングに割り当てる時間は確保されないし。そんな環境で生き残るためには、仕事の合間に技術習得していくしかない。プライベートはとても良い学習時間だけど、チームメンバにそれを期待するのは筋違いだよね。

って、相変わらずグダグダな話になってきたけどw

システム開発では、より良いプログラムを書くことを目指すべきだし、チームメンバにはより良いプログラムを書いてほしいと期待すべきです。言い換えれば、チームメンバに対して、より良いプログラムを書く権利を与えるべきだと思っています。何よりも自分が、今よりも良いプログラムを書きたいから。

こんな流れで「開発プロセスについて理解を深める必要があるよね」となって、「2009-05-16(sat)に開発プロセス勉強会…的な何かをやります - @katzchang.contexts」につながってるわけです。