レガシーコード改善ガイドを読んでいこうと思う

毎週チーム内でレガシーコード改善ガイドを題材に読書会をすることになった。

もともと周りのプログラマーからの評判がよかったのでいつか読みたいと思っていたが、本格的に読んだほうが良さそうな状況になったのでこれから読み進めていく。

ここでいうテストとはUnitTestのことだ。

自分はテストコードを書くようにしている。テストがないと不安でコミットできない。コミットするソースコードに対してはテストを書いて実行し、振る舞いが期待通りであることを確認してからコミットすべきだと思っている。（プライベートで開発しているどうでもいいプロダクトは別として）

テストが通っていないということは期待通りの振る舞いをする保証がないということだ。全てのテストが通っているからといってバグが発生しないわけではないが単体レベルでの振る舞いは保証される。

しかし実際の現場でテストが存在しないプロダクトは意外と多い気がする。Excelで書かれた結合テストのシナリオはあったりするけど

自分が書いたコードに絶対の自信があるからだろうか？そもそもテストの導入の仕方がわからないからなのか？

ちなみにテストを書く人ほどわかりやすくて人に優しいコードを書く傾向にあると思う。（自分はまだまだだけど。。。）

理由はどうあれテストはあった方がいいよという話。

（あった方がというよりないとダメ）

自分は最近新しいチームにジョインし、既存システムの開発をすることになった。

チームメンバーは話しやすく積極的にコミュニケーションを取れそうな感じですごくいい！

チームにジョインしてすぐに開発に入ることになった。

最初は簡単な改修や機能追加だ。

ディレクターさんに仕様を共有してもらいながら実装のイメージを膨らませていく。

仕様の共有が終わり、開発に入るためまずは既存のコードを読んでいく。。。

。。。

テストがない！！！

しかも

Viewに書かれた大量の業務ロジック！

条件文に現れる何かを意味する大量のマジックナンバー！！

Controllerにも大量の業務ロジックが！！！しかも数千行はありそうだ。。。

条件文やループのネストもなかなかに深い。。。

改修、機能追加をしたいがエンバグが怖い。。。

「ここを修正したいけど他に影響は出ないか？そもそも影響範囲は？」

振る舞いがどのように変わってしまったかを確認する術がない。。。

テストがないからだ

しかし既存の機能を壊すようなことだけはしたくない。。。

レガシーコード改善ガイドを読んでいくことでチーム内に浸透させたいことはざっとこんな感じ

レガシーコード改善ガイドを読んだ後で実際のプロダクトにテストコードを書いていければいいなーと思っている。

既存のコードをテストに入れるのは簡単ではないが、今あるプロダクトをよりよくしていきたいという思いはあるので頑張りたいと思う！

今後は読み進めた部分に対してまとめ、備忘録的な感じで記事を書いていければと思う。

よし、頑張ろう！

yusuke921's blog