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

リファクタリングを日課にする

雑記

リファクタリングの目的は、「メンテしやすい」「変更に対して強い」コードに仕上げることであると考えています。
「変更に対して強い」とは、改修や機能追加において変更による影響が少なく済むことを指しています。変更による影響が必要以上に発生するコードは「変更に対して弱い」ということになります。

どのようにリファクタリングをするか

命名/フォーマット

コードは人が読むものであり、コードの意味や意図が読み手に正しく伝わる必要がある。自分を含めて読み手が読みやすく書くように心掛けることが大切である。

  • コードの意味/意図を正しく表すようにクラスやメソッド、変数に命名する
  • インデントやスペースを適度に入れる
  • フォーマットする

このあたりは、コーディング規約を定義したり、フォーマッタを準備することである程度はカバーできる。ただし、コードのフォーマットとロジックの変更は同時にコミットしてはいけない。(ロジックの変更箇所が埋もれるのを避けるため)

冗長/重複コードをなくす

冗長なコードはシンプルにする。無駄なコードは削除し、長すぎるロジックはいくつかまとまった処理ごとに分割できないか検討する。

重複コードは共通化する。ただし、なんでもかんでも Utils 的なクラスに放り込んではいけない。 アプリケーションのアーキテクチャをきちんと考えておくと、そのロジックを実装するべきレイヤ/クラスが明確になる。(と思う)

いつリファクタリングをするか

コードは書いて終わりではなく、自分で書いたコードは読み返す癖を付けるとよい。ある程度、自分が納得できるレベルになるまでブラッシュアップする。(プログラミングだけでなく普通のドキュメントやメールなどでも同様)

ただし、リファクタリングをしているとやめどきがわからなくなることがある。

冗長/重複コードのリファクタリングであれば、「冗長/重複がなくなるまで」という明確なゴールがある。しかし、明確なゴールがないリファクタリング(命名の変更など)では、納得感が得られないとなかなかやめられなくなる。

このあたりは、ある程度のところでやめるように自分をコントロールするしか対策はなさそう。

リファクタリングをする/しないは、個人の「意識」によるところが大きいと思う。ドキュメントやコードがシンプルで DRY であること、常に改善するという意識を持っている人であれば問題ない。

個人の意識に依存しないようにするには、「コードレビュー」によってリファクタリングをする機会を作るとよい。

PRベースで開発しているプロジェクトであればコードレビューをすることが多いはず。
それ以外のプロジェクトでは、「チケット駆動開発」などのワークフローを取り入れて、開発のプロセスとしてコードレビューを実施するとよい。

まとめ

リファクタリングは日課にしよう。1日30分~1時間でよいので、「今日はここを直す」みたいな感じでテーマを決めて改善する時間を作ろう。