リファクタリング

Fullerさんはリファクタリングを積み重ねることを推奨する理由として、「コードは書くよりも読む方が難しいが、読んで得られるものは大きい」ことをあげています。

時にはコードをすべて書き直すことも必要。その絶好の機会は製品そのものを見直す時だとFullerさんは述べています。

製品を取り巻くビジネスが不調であり、製品の開発者たちもコードに不満を持っている時

非常に複雑で品質が低く、一部を変更すると必ずバグが出てしまうようなコード

sta.icon

ちゃんと分解していって愚直に取り組むことが大切なのね

テストコードなくても進んではいける

ソースにもよるだろうが

やっぱりビジネスサイドの説得は必要

この例だとあっさり受け入れてもらえた

きっかけ

負債積み重なっていってて腰が重たい日々

人が増えたので、やっていこうか

どこやるかの基準

直近触る部分

多くの開発者が負担だと感じている部分

リファクタリング後に得られる効果

可読性の向上による効率低下防止や見落とし防止

統一性の向上によるIDE利用（による効率化）

どう取り組んだか

パターンに分けて、パターン毎に方針、設計、見積もりなどを実施していく

タスクは3-4hで取り組める粒度に

優先タスクが降ってきたらそっちができる（いったんリファクタリング系タスクは捨てる）ようにする

misc

文字列として埋め込まれていたコードを分離

ハイライトされないとレビューつらすぎる

テストコードは十分ではなかった

ビジネスサイドへの説明

とくにそういうことはなく、説明したら「あ、なるほど」と受け入れてもらえたので。

ストック化

オフショアチームのスケジュールに余裕が生まれた時の追加依頼ストックとして用意しておくと、すごく精神的に安心感があってよかったので、今後も続けていきたいなと思っています。