【プログラミング】オーバーエンジニアリングしないために

ども、カニカマです。カナダでアプリとかを作ってます。

たまにはプログラミングの話もしてみます。

オーバーエンジニアリング問題

僕が仕事でプログラムを書いてる時に気をつけていることがあります。
それはオーバーエンジニアリングになっていないかということ。

オーバーエンジニアリングとは、必要以上に複雑であったり高度な技術を使って開発したりすることです。

「やり過ぎ」みたいな状態です。

例えるなら、近くのスーパーに買い物行くだけなのに、着替えを上下３枚づつ用意して、停電の時のための懐中電灯と電源と食料を用意してみたいな状態です。絶対必要ないでしょ。

プログラミングやったことない人には、なぜ必要の無いことをやったり複雑なことをあえてするんだろうと不思議に聞こえるかもしれません。
時間も余計にかかるし、コードも分かりにくくなるのに。

でも実際にはめちゃくちゃ起こります。僕も何度も遭遇しました。

• 必要以上の抽象化
• ゴリゴリのパファーマンスチューニング
• アーキテクチャの乱用
• 「もしかしたら使うかも」をベースにした拡張機能の実装

こういうのですね。

なにが悪い？

単純にいらんでしょ！ってだけです。

オーバーエンジニアリングのコードは複雑になりがちです。
コードが読みにくくなる、それによってメンテナンスが大変になる。
それによってバグが増える。
リファクタリングでの修正が難しくなる。
余計な時間とコストがかかる。

いいことないですね。

なぜ起こる？

特に新しいプロダクトを作る時、新しいコードを書く時に生まれやすいかもです。

プログラマーの感覚として「変更があった時に効率よく変更できるようにしておきたい」っていうのがあると思います。

プログラマー的に考えることは
「今はユーザーが１００人だがもっと増えたらどうだろうか？耐えれるか？」
「将来的に拡張できるようにした方が役立つのではないだろうか？」
「先々で楽になるのではないだろうか？」
みたいなことを考えます。

そしてオーバーエンジニアリングは生まれます。
余計な時間とコストをかけて、結局一生使いもしない複雑なコードが生まれるんですね。

他にも大きな原因はいくつかあると思います。

ひとつは要件定義の曖昧さ。
いま、そのプロジェクトで必要なものが見えていないだったり、フォーカスできてなかったりします。
100人と100万人が使うプロダクトでは設計も必要な課題も違います。ゆくゆくは100万人のプロダクトにするにしても、そこまでは必要のない実装はかえって複雑なコードを生み出すだけです。
ここはビジネスサイドの原因もあるので、ビジネスサイドとのコミュニケーションが必要不可欠になってきます。
今それが必要か？ってことですね。

そして開発者のエゴ。
ちょっと経験を積み始めた人、経験豊富な人、技術好きな人に多いかも。

プログラマーの新しい技術を試してみたいという欲求を満たすために、ついついオーバーエンジニアリングしてしまうパターン。
しかも将来の準備という正当化もできてしまうことがある。

それ以外にも必要以上にパフォーマンスを追求したり、キレイに書かなければという一心でオーバーエンジニアリングするパターンもあります。
この場合もそれ自体は悪いことではないのでタチが悪いです。

できるだけ無くしたい

オーバーエンジニアリングを出来るだけ無くしたい！と常々思っております。そのためにどうすればいいのでしょう？

出来るだけ「今必要な要件を明確にする」がいいと思います。
将来のことよりも、今そのプロジェクトに必要なもの。
今、最低限必要とされているものを効率よく実装するのがいいかなと思います。
将来のことは、将来に考えた方がいいと思います。

ましてや新しいプロジェクトやプロダクトであればなおさら。最初考えていた要件はどんどん変わっていくものです。

シンプルにコードを保ちつつリファクタリングを定期的に行うように、プロジェクトを回して言ったほうがよっぽど健康的な気がします。
変更することはもう前提でいた方がいいと思います。

あとは、一度に全部の問題を解決しようとしないで少しづつアップデートできるようにした方がいいと思います。

出来るだけ業界のベストプラクティスにそって、魔改造した設計を避けるようにしましょう。と思うわけです。

YAGNI

有名なソフトウェアの原則で
YAGNI (You aren't gonna need it) ってのがあります。
直訳で「それいらんでしょ」です。
後で使うだろうという予測の元に作ったものは、実際には10%程度しか使われないそうです。したがって、それに費やした時間の90%は無駄になります。
必要なものは必要になったときに書きましょうってやつですね。

KISS

こちらも有名なソフトウェアの原則
Keep it simple stupid
直訳で「シンプルにしとけバカ！」とかですかね。

というわけで

将来を見据えてコードを書くことはとても重要なのですが、全体的にそれがオーバーエンジニアリングになっていないか、または余計な実装で時間と複雑性を増やしていないかを常に意識しないといけないなぁと思います。

僕の頭が悪いので、理解するのに時間のかかる複雑なコードは書かないで欲しいなって話です。
シンプル・イズ・ベストでお願いします。

ではでは。

#仕事について話そう