今月はマーティン・ファウラーの『リファクタリング 既存のコードを安全に改善する』を読んでいる。
というのも、ここ半年くらい所謂”レガシー”なコードと対峙していて、なかなか苦しい時間を過ごしているからだ。
当時の開発者はすでにおらず、込められた意図はコードから想像するほかないのだが、
同時にこう書けばより良いのでは？というような見方もできる訳で、もう少し向き合ってみようといつも自分をなだめている。
自分が持ち合わせていないベストプラクティスを習得するのに格好の時期と思い、本書を手にした。
リファクタリングとコードレビュー
“リファクタリングとコードレビュー”というタイトルとしたのは、前回に引き続き私の関心事がコードレビューに向いているからだ。
本書では第２章「いつリファクタリングをすべきか」にて、”コードレビュー時のリファクタリング”という節が登場する。
こう書けばより良いのでは？というのは、ある意味では他人が書いたコードレビューをしていることにほかならない。
そのアイデアをコードに反映できたならば、それはまさにリファクタリングしたと言えるだろう。
さて、コードレビューの目的については前回取り上げたマティアス氏の見解とほとんど一致していた。
コードレビューは開発チーム全体に知識を浸透させるのに有効です。 (中略) 大規模システムのさまざまな特質をチームに周知させることができます。
なかでも、以下は示唆に富んだ内容でハッとした。
明快なコードを書いているときにもレビューは重要です。 自分にとってわかりやすいコードも、チームにとってはそうでないかもしれません。
前回の記事で述べた、コードレビュー時に自身が取り組んでいる”テキストベース＋対面でのフィードバック”という方法について、背中を押してもらえるような見解があった。
テキストベースでのフィードバックとは、言い換えると”プルリクエスト方式で実装者がそばにいない状況で評価すること”とも言える。
一方、対面であれば、”コードのコンテキスト・レビューの意図が十分理解できる・伝わる”のである。
後者のタイミングでリファクタリングも行う(つまりペアプログラミングの状態)ことで、常にコードレビューとリファクタリングという行為がプログラミング内に織り込まれるようになるという考えだ。
このことは自身の実体験を踏まえても膝を打つ内容で、自己流のヒューリスティックが確信に迫る一文であった。
今後のコードレビューの１手法として確立していきたい。
