最適化のタイミングとバランス

Premature optimization is the root of all evil — DonaldKnuth
時期尚早の最適化は諸悪の根源である（Google訳）
http://c2.com/cgi/wiki?PrematureOptimization

この数ヶ月間、私たちは過剰すぎる最適化がおこなわれているソースコードの修正に多くの時間を費やし、また、大変消耗しました。

ということで戒めのエントリー！

この記事で扱う「最適化」とは

この記事ではプログラムの共通化、もしくはYAGNIのような、コードの冗長化対策としての最適化について述べます。

最適化の時期

複数人での開発の場合、プロジェクトの初期～中盤までは、多少冗長でも可読性とわかりやすさを重視するのが良さそうです。

ウェブアプリケーションフレームワークの利用により、システムレベルでの共通化は満たされているとして、共通関数を作成する場合に、処理分岐のためのパラメータを関数に渡す必要がある場合は、共通関数としないようにしましょう。
違うアプローチとしては、オブジェクト指向のポリモフィズムで実装できれば上記の問題を解決できる場合があります。

誤った共通化

共通化は慎重に。

一般的に、書き始めたコードはシステムが大きくなるにつれ、処理が複雑化します。
早いタイミングで場当たり的な最適化をおこなう場合、この複雑化に対応できず、その場しのぎの処理を記述しなければならなくなります。

業務か趣味か

最適化にも工数が必要。

冗長でも正しく動作しているコードの最適化をおこなう場合、「システムの動作は全く変わらないが、作業工数がかかる」という問題を考えなければなりません。
システムの動作が変わらないんだったら、必要になるまではそのままにしておいて、他の業務やったほうがいいんじゃないの？
ということをちゃんと考えてからやること。あと、やる！という意思表明に対して誰かの合意が必要。

特に受託開発の場合は、作業工数に対して見積もりをおこなっているため、ある程度の割り切りは必要です。最適化の際に見積もりに対して確認工数がかかりすぎる場合はわりきって諦めます。赤字になっちゃうからね。

まとめ

優れたプログラマは、ガマンとあきらめと最適化のバランスが上手くとれているような気がします。
「あ、ここも最適化できる！」は、趣味でやって、感覚を掴んでから業務に活かしましょう。

１．最初からできるかぎり最適な設計ができるよう精進する。
２．チーム開発では可読性を重視する
３．直感で最適化しない。
４．コードを憎んで人を憎まず

といっても、難しいんだなぁこの問題は。

参考

若手開発者が大聖堂のように完璧に作ったと思ったものは、ベテラン開発者から見ればスラムのように混沌としていました。若手開発者には秩序があったように見えていたものは、ベテラン開発者にしてみればただの錯綜したネットワークでした。
http://postd.cc/the-sorrows-of-young-developer/