読者です 読者をやめる 読者になる 読者になる

How IT Works

プログラマーやっています。技術よりも人間学的なところが好きです。

作業と順番

背景

 業務であっても、趣味であってもプログラミングをしていると、当然コーディングをして終わりということはありません。

 大抵、コードをリファクタリングする作業が必要ですし、場合によってはパフォーマンス改善(メモリの使用量削減、レスポンス改善等)に取り組むことがあります。

 今回考えたいのは、どの作業にどのタイミングでとり組むべきなのかというところです。

 自分はとりあえず動くコードを作る>リファクタリングですべての機能を作りこむことが多いのですが、最近はそうしないほうがいいのかなと思い始めてきました。

機能を作りこむ>リファクタリング>パフォーマンス改善

 自分はまず動くコードを作ることが多いです。

 多分、テスト駆動開発(TDD:Test Driven Development)に影響を受けていて、まずは動くコードを作って徐々に作りこんでいくのが好きです。

 こうすると純粋にロジックに集中できるので効率的に開発できる気がします。そこからリファクタリングをしてとりあえず作業は終了して、全部の機能を作りこみます。
 そして、ボトルネックになっている箇所があれば、パフォーマンス改善にとり組むという具合です。

 機能が一番重要で、パフォーマンスは後回しという考え方が背景にあります。

パフォーマンス改善>機能を作りこむ>リファクタリング

 逆にチームのメンバーは最初からパフォーマンス改善を考慮して設計します。

 そのうえで、機能を作りこんでいって、最後にリファクタリングをします。

 この順番で行くと納期が押していくと最終的にリファクタリングを切り捨てることになります。

 逆にメリットとしてはアーキテクチャの変更が最小限で済むということがあります。

 パフォーマンスを改善するときは大きなアーキテクチャの変更が必要なことが多いので、先に配慮しておくと修正が最小限で済みます。

個人的な結論

 これまで先にパフォーマンス改善をするやり方は「過剰な最適化」「早まった最適化」の類だと思って避けていました。

 ただ、現在の業務ではほぼすべてのケースでパフォーマンス改善の要求があって、逆にリファクタリングの効果が下がっていきます。

 それに会社全体としてリファクタリング自体が評価されない傾向にあるので(そもそもコードレビューもない)、他のメンバーに合わせるのがいいのかなと思うようになりました。

 もちろん、データ構造を大きく変えるとか、データ型を変えるとかそういった最適化は最終手段にしたいですが、アーキテクチャレベルの設計判断は早めのほうが自分の状況ではいいのかなという感じです。

趣味

 では、趣味はどうすべきなのかなと考えると、やはり同じなのかなと思います。

 趣味で何かを作っているとどうしても動くコードを作ることに腐心しがちなので、開発環境、パフォーマンス改善、リファクタリングその他もろもろが後回しになります。

 だから、コードを書くということの優先順位を少し下げて、学びに集中するくらいが自分にとってちょうどいいのかなと思います。