2015年の振り返り
少し時間が経ってしまったが、以前自分が書いた振り返りブログを見返すと当時のことを鮮明に思い出せて「ああ、こんなこともあったなぁ。こんな感想持っていたのかー。」という感じになっておもしろかったので、2015年分の振り返りも書くことにした。
時系列に沿いつつ、特に印象に残ったテーマ単位で振り返る。
古くなり手を付けられなくなったレガシーコードの大幅リファクタリング
開発から年数が経ち、日に日に複雑化してレガシーコードと化してしまった検索系APIの大幅なリファクタリング(のための準備)を行った。
- グローバル変数が何個も使われている
- 1メソッドが肥大化して400行を超えている
- 1つの変数が参照渡しで様々なメソッドに渡され、処理を追い切れない
- テストが無い
というような状態で、手を付けられる状態ではなくなっていた。開発者も何が影響してバグを生み出すかわからないから手を出したくない。 しかしこのAPI、サービスにとってかなり重要な機能を提供していたため、企画さんや営業さんから絶え間なく機能追加要望が来て いるという状況だった。
これは良くないということで、チームメンバーで相談し合い、多少時間がかかっても良いからリファクタリングをすることに決めた。それが将来的に見てプラスになると判断した。
自分が担当したのは、最初にこのAPIの仕様を正確に把握してテストに落とすことだった。 APIなのでviewまわりの処理を気にする必要は無かったが、受け取るパラメータが80個(!)くらいあって「ウッ..」っとなった記憶がある。
あまりテストを書いた経験が無かったので、正しいかどうかはわからないが、次のような方針でやっていくことにした。
- 外側から見たAPIの仕様だけをテストにする。つまり、内部的な実装のテストではなく、API利用者の視点のテストを書いていく。
- テストはリクエストパラメータ単位で書く
1
は1つのメソッドが長すぎてテストに落とすのは難度が高かったのと、これから大幅にリファクタリングされることもあって単体レベルのテストを書くのは無意味だと思ったので、機能面でのテストだけを書くことにした。例えば次のようなテストである。
1. パラメータ「price_from」に100を渡すと、100円以上の結果のみが返ってくる
2. パラメータ「price_from」に100を渡し、「price_to」に1000を渡すと100円以上1000円以下の結果のみが返ってくる
2
についてはそのままの意味で、受け取り可能なパラメータごとに仕様を整理してテストに落とすということ。何でも良かったのだが、何かしらグループ化できると進行状況がわかるし、開発も進めやすいと思ったのでこのルールを作った。
リファクタリングが完了する前に自分は別の部署に異動してしまったので、最終的にこのリファクタリング作業がどうなったかは実は知らないのだが、上の方針でテストを書いてみていくつか感想をまとめたい。
機能テストは効果が高い
機能面でのテストは、関数など単体レベルのテストよりずっと効果が高いと思った。 現実での使われ方と同じ形でテストをするので(APIの場合、HTTPリクエストをするという形をとるので)、信頼性が高く感じた。 また、内部的な実装はどんどん変わっていくが、API自体の仕様は頻繁には変わらないので保守性の面でも良いと思う。