レガシーソフトウェア改善ガイド (Object Oriented Selection)
- 作者: クリス・バーチャル,吉川邦夫
- 出版社/メーカー: 翔泳社
- 発売日: 2016/11/11
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
入社以来比較的新し目のプロジェクトしか触ってこなかったけど、最近はチームが移動になり古めの(古めというか社内最古クラス)のサービスを扱うことになったので、社内で読んでいる人が良さそうと言っていたこともあり読んでみた。
結果としては非常に参考になった。どうアプローチしていけばいいかの型を提供してくれる本であるから、これを元に自分たちにあった方法を模索していきたい。
以下は参考になった部分と感想。
恐れ
レガシーなプロジェクトへ
- 少し変更するだけでぶっ壊れてしまう
- 修正が必要ない箇所には気になっても手を触れずにいよう
みたいな印象を持っているのであればそれは「未知への恐れ」である。感感俺俺を示してくれている章。
つまり、恐れを取り除くために調査的リファクタリングをしましょうと言っている。調査的リアクタリングとは、コードへの理解を深めることを目的としたリファクタリングのことである。自分は失効コードを消したり、振る舞いがわかりにくいコードにコメントをつけたりする程度で、レビューしてくれる人がシュッと見れる程度の変更にとどめて実施していった。ちなみにどういったコードをリファクタリングすべきかみたいな話は1章丸々割かれて説明されている。
調査的リアクタリング際はチームを巻き込んでペアプロっぽくすすめると良いとも書かれていてこれは最近痛感している。
- チームメンバーのほうが圧倒的にプロダクトに詳しい
- 別々に作業してもレビューの際に確認しないと行けないので無駄
というのが主な理由。前者は僕への教育的な意味で効率の良さで、後者はチームとしての効率の良さである。つまりスループットを挙げるためのペアプロなので例えばチームメンバーがコードを触ることになった際にもペアプロでやれば良さそうである。結局僕がレビューするわけだから、「理解せずにレビューする」か「理解してないがゆえ周辺コードを読み始めてロスが生じる」かの二択なのでだったら最初から一緒にやろうという考えである。
ユニットテストなしのリグレッションテスト
自動テストは用意されていないという状況で自分たちの変更が正しいかどうかを見極めるのは非常に難しい。社内の通常のプロジェクトであれば自動テストもあるしステージング環境での用意されているのであまり意識しなかったが、そういったものがないプロジェクトでどのようにサービスが正常に動いてるかを判断するかはコスパを鑑みて考えなくてはならない。つまり積極開発していないプロジェクトに置いて自動テストの導入やステージング環境での確認作業がコストに見合っているかということである。
正常であることの確認は複数の方法があると思うが、自分はまずエラーログの監視から始めた。これは以前携わっていたプロジェクトであったら普通のことであったけど、レガシープロジェクトだとそうもいかない。ログの流れが早すぎて出てはいけないログが何なのか全く把握できないという状況であったからだ。というわけで自分はまず
- 直すのが簡単そうな警告であれば直してしまう
- 誰も監視していなければそもそも意味は無いので警告のしきい値をぐっと上げる
などの対処を行っている。エラーログの出力基準を変えずに、capのエラーログ監視のタスクで tail のあと grep -v hoge みたいにフィルタリングしてもいいと思うが、結局見ても意味のないエラーログに意味は無いので、不必要なログはそもそも出力しないという方針で進めている。あとはロールバック手順を明確にしておけば万が一のときでも素早く異常を察知できもとに戻すことが可能になる。
もちろん、大きめの変更はステージングに出す、特定ユーザーだけ振る舞いを変えてテストするなどベストなリグレッションしていないかの確認手段はケースバイケースなのでそのときにあった選択をしていきたい。
ビッグリライト
今自分がやりたいこととはずれるが、興味深かった。
まとめ
やっていき。
