書籍「リファクタリングruby」2章 ~ リファクタリングの原則 ~ を読み直してみました。また内容を忘れた頃に摘んで読みたい内容をいくつか書いておこうと思います。

機能追加とリファクタリングという別々の活動のために時間をはっきり区別すべきだ 自分が現在どちらの作業をしているか意識する必要がある

そもそも機能追加は既存コードの処理を変えずテストを追加するのに対し、リファクタとは既存コードを変更しテストは変更しないといったように手法が異なるからですね。確かに混ぜて作業を行うと効率が悪そうです。

私は、コードが何をしているのかを理解しなければならなくなるたびに、その理解が最も早く得られるようにコードをリファクタリング出来ないかということを考えるようにしている。そして、リファクタリングを行う。読みながらコードをわかりやすくすればより多くの事が理解できる。

既存プロジェクトに途中でJOINする場合は、機能追加の前にその機能周りのリファクタをしながら理解を深めるのも良さそうですね。何かの機会に実践してみようと思います。

設計変更は高くつくので、予測できる変化に耐えられるように設計を作ろうとした。柔軟な解(設計)は、単純な解よりも複雑になるのだ。 変更はシステムの障害を通じて発生し続ける。それらすべての箇所に柔軟性をもりこんでいったら、システム全体が非常に複雑になりメンテナンスにコストがかかるようになってしまう。 柔軟性を得るためには、実際に必要とされるよりもずっと大幅に柔軟でなければならないのである。

リファクタリングの習慣があれば、柔軟な設計を考えることなく単純な方を選択できるため設計プロセスの重圧が軽減されるとのこと。単純な方に方向をたおし、必要になった時にリファクタすれば良いという感覚なんだとか。

パフォーマンス改善のために、システムの内部で何が行われているかを正確に理解していたとしても計測せよ。推測に走ってはいけない。推測で何がを学ぶかもしれないが、10回に9回までは、正しくない。

RubyKaigi2014の基調講演スピーカーのaman gupta氏もプロファイリングし徹底的な計測を行っていましたね。




comments powered by Disqus


© 2015 kyuden