業務エンジニアの攻撃は最大の防御ブログ

業務エンジニアのブログ。業務システム大好き。フレームワーク開発も好き。

オブジェクト指向やデザインパターンはどんどんやるべき

オブジェクト指向にこだわった設計をしたい」「デザインパターンを使って良い設計にしたい」という人がいればドンドンやればいいと思います。
少なくとも個々の開発者の成長のためにはドンドンやらせるべきだと思います。
不真面目な考えかもしれませんが、そう思います。

色んな人が「オブジェクト指向デザインパターンを中途半端な知識で使うな」という趣旨の事を仰っています
正論です。パターンや設計手法は「考え方の見本」であり、それらを考えなしに使うというのは本末転倒です

中途半端な知識でオブジェクト指向デザインパターンをやろうとしたせいで処理が追いにくいだけのゴミの集まりになる事は数多くあります。
そのために、無駄に保守コストがかかったり、自分自身でそういうソースを書いてしまって後悔したりといった例も枚挙に暇がありません。
そういった経験から、デキる人達は警鐘を鳴らしておられるのだと思います

けれど私はやはり、
「やりたいならどんどんオブジェクト指向デザインパターンをやったみたらいい」
と言いたいです。

だって、経験を積まないと学べない事ってあるじゃないですか。
既にデキる人達は、
「あ、これはオブジェクト指向を誤解した奴が設計してるな」とか
「XXXパターンをやろうとして、どうしようもなく読みづらいソースになってるな」とか
そういう事が感覚で分かります。
でも、これから経験を積んでいく人達は、そういう感覚がまだないのです。
色々挑戦して失敗から学んでいくしかありません。
最終的にそのプロダクトでは失敗しても、自分の中でベストな「オブジェクト指向設計デザインパターン」をやってみて次のプロジェクトに活かせたらいいと思います。

上記のような態度については、「仕事で実験すべきじゃない」「後からコードを保守する人の事も考えろ」と言うご意見もあるでしょう。
それは正論です。

でも、それでも私は挑戦したいという人達を止める気にはなりません
なぜなら、クソコードが生まれる事はどちらに転んでも避けられないからです。

オブジェクト指向にこだわったせいでクソコードを書いてしまうような経験の浅い人は、たとえオブジェクト指向を禁止されてもクソコードを書いてしまいます。
そういう人(要はまだ経験の浅い人)が詳細設計やプログラミングを担当している時点で、どういうルールを敷いてもクソコードは必然的に生み出されるのです
どうせクソコードになるのであれば、とにかく今の理解で出来るかぎり良い物を作る努力をして次に活かした方が良い。
その方がその人の成長に繋がり、結果としてこの世に生み出されるクソコードはトータルでは減ると思うのです。

ただ、個々の開発者・設計者が自分の理想だけを追い求めて、後始末を保守担当者に丸投げしては製品もプロジェクトも崩壊します。
最低限のモラルは守るべきだと思います

例えば、

  • 理解や知識が完璧じゃなくても、自分の中ではどうしてそういう設計や実装にしたか説明できる(よく分からないけどとりあえず流行りなのでやってみようという態度はNG)
  • 少なくとも、同じプロジェクトの平均レベル以上の品質は出せる自信がある(仮にクソコードになっても、少なくとも他のコードよりはマシにする)
  • プロジェクトが終わった後もずっと学び続けて、今回の失敗は次のプロジェクトで取り返す

くらいの意思がない人には挑戦を許してはいけないと思います。