経験をもっとすべし
色んな人が「オブジェクト指向やデザインパターンを中途半端な知識で使うな」という趣旨の事を仰っています
正論です。パターンや設計手法は「考え方の見本」であり、それらを考えなしに使うというのは本末転倒です
けれど私はやはり、
「やりたいならどんどんオブジェクト指向やデザインパターンをやったみたらいい」
と言いたいです。
オブジェクト指向にこだわったせいでクソコードを書いてしまうような経験の浅い人は、たとえオブジェクト指向を禁止されてもクソコードを書いてしまいます。
オブジェクト指向プログラミングの経験不足が今のプログラマに否めないのは、彼らの責任ではない。彼らの現場がオブジェクト指向開発でなかったり、彼らの先輩、上司がオブジェクト指向に疎いからである。
本来プログラマは好奇心が強い。技術習得のために講習会に出たり社内勉強会を積極的にするとかしたいのである。然しそうした技術習得をしてもその先に使える可能性がほとんどないのであればその努力は無駄となる。それではモチベーションはあがらない。
であれば営業はできるだけ新技術を使った開発を受注したり、あるいは管理者も自ずから新技術を学びそれを実際のプロジェクトに適用する。同時にプログラマを講習会にいかせたり社内勉強会を支援するなどの企業努力が必要である。
然しそれでも未経験というリスクがある。
例えばデザインパターンはよい設計のテンプレートだが経験がないとうまく使えない。経験不足で使うと逆効果となるリスクがある。これは未経験の者が誰でも通るどうしようもない壁である。
であれば仮想プロジェクトで経験すればよい。
最初の経験をリスクなくこなせるのが仮想プロジェクトである。いや、リスクはあるがそれが顕在化したところで損害はない。これは仮想プロジェクトの強みである。こうした仮想プロジェクトへの参加は講習会などで経験できる。
或は自社で実験プロジェクトを企画し経験してしまうのもよい。
そうやって次回の本番までに経験しておく。それでリスクは減るのだ。もちろんリスクがゼロになることはない。だがそれは経験数が増えても同じである。だからとりあえず一度経験したら本番プロジェクトにチャレンジすればいい。
然し、そうした仮想プロジェクトに参加するチャンスのないプログラマもいるだろう。そういうプログラマはどうすればいいのか。
「やってしまう」しかない。
賭けである。
もちろんそのためには最低限しなければならないことがある。
リスクを承知でやるとしてもそれを回避するためのリスクマネージメントをしなければならないということだ。それを調べることが経験の代わりになる。
当たり前だがお客様の損害のリスクヘッジを最優先にしなければならない。そのためには工夫も必要だ。失敗しリスクが顕在化した場合の覚悟も要る。無間残業地獄が待っているかもしれない。下手すればクビである。その上で「使ってみたい」という欲望にかられたなら使うしかないではないか。なら、使え！使ってしまえ！
リスクシミュレーションをしながら真剣に技術を研究し挑戦するというぎりぎりの状況でこそプログラマは常識では考えられない飛躍的な技術的躍進に導かれるのだ。
そしてこれは多くのプログラマが経験する道でもあるのだ。
