matobaの学んだこと

とあるPythonエンジニアのブログ。ソフトウェア開発、執筆活動、ライフログ。

ソフトウェアをリファクタリングするということ

リファクタリングについて調べてます。

この記事の続き。

リファクタリングについて調べはじめた - blog.mtb-production.info

キチンとしたリファクタリングのやり方を知りたいと思ってます。*1

というわけで、この本を読んでます。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

本を読んでいて、自分なりにポイントだと思ったことを書いています。最後に所感も書いてます。

リファクタリングの頻度

リファクタリングは定期的にやることではなく、何かをやる時に一緒にやること。

  • Bad:定期的(例えば、二週間に一回)やる。
  • Good:リファクタリングするべきタイミングでやる。

リファクタリングをやること

リファクタリングは目的ではなく、手段である。

リファクタリングのタイミング

次のようなタイミングでやる。

リファクタリングしないとき

次のタイミングでは、リファクタリングを避けます。

  • コードが汚すぎて書き直す方が早いとき
  • 既存コードが動かないとき
  • 締め切りが迫っているとき

なにをリファクタリングするか

  • じゃあ、なにをリファクタリングしたらいいの?ってと言うと、不吉な臭いのするコードリファクタリングする。
  • 不吉なコードを嗅ぎ分けるスキルは経験によって養われる。

所感

この話の中だと、一番良かったのが、何かを対応する中で理解のためにリファクタリングするということ。

ちょうど、開発してるコードでも、新しい機能を作ったら、元のコードで気になる部分が出てきていた。

新しく作っている機能がなかったら気にならなかったけど、新しい機能を追加したら気になることがある。

たとえば、新しい機能があることで既存機能の変数名が誤解を招くとか、無駄な処理があるとか、そもそも、設計が微妙になるとか、そういうやつ。

そういう微妙ななにかは、新しい機能を追加するときにわかるし、それはリファクタリングすべきコードだということがわかった。

そして、リファクタリングした際に、デグレートしてないかを確かめるためにユニットテストが有効に作用する。

ユニットテストがしっかりしていれば、リファクタリングがスムーズにできることがわかってきた。

あと、これまではユニットテストを書くのが遅かったけど、ユニットテストを書くスピードが上がれば、ソフトウェア品質と開発スピードを保ったまま、ソフトウェアを拡張していけることがわかってきた。

これまで、設計した後にコーディングをする。そして、コーディングの段階で、設計を修正しないといけないのがわかったら負け。みたいなマインドがあった。

コーディングする前に、設計が全部わかるわけないでしょ。と思っていたけど、『僕が実力不足なだけで、できる人ならコーディングする前に設計が終わるのかもしれない。』とも思ってた。

ただ、この本を読みつつ仕事をしてる中で真実はこうでは?と思ってることがある。

  • 設計してからコーディングした方が良い。(必須ではない。規模、複雑さ、何回使いまわすか、による。)
  • コーディングする前に設計が完了するときもある(だいたい作ったことがあるシステムと、全く同じものを作る場合は近いかもしれない。ただ、ホントにそんなことある?チュートリアルか?)
  • 設計してからコーディングして、その後に設計を修正することはある。(必ずではない。コードの目的が何なのかによる。)
  • 前は良かった設計が、新しい機能追加によって悪い設計になるときがある(拡張性が高ければ良い設計ではない。拡張されないのに、拡張ポイントを作ると、逆に読みにくいコードになる。コードが読みにくいければ良い設計とは言えない。)
  • 時間と共に設計は、腐っていくので改善しないといけない。(周辺環境によって、設計が良いか悪いかは変化するし、周辺環境は時間と共に変化していくので、それに合わせたリファクタリングが必須。)

とりあえずおわり。

*1:キチンとした、ってなんか型にハマってて、書いてあることしかやらなさそうな響きが個人的には好きじゃないんだけど、そういうのはとりあえず基本をしっかりしてから言う事な気がしてるのでとりあえず基本的なことをやりたい気持ち。