約3年続くリファクタリングを引き継いで見えたテクニック by k-kohey

ソフトウェアは一度作ったら終わりではなく，その後もソースコードを保守管理しなければいけないというのは今では常識になりつつあります．
積極的に大きなビジネスインパクトを狙い，日々ソースコードの編集を繰り返し，頻繁にリリースを行うことも珍しくはありません．
このようにソースコードへ頻繁に手を加える必要がある際に，レガシーコードは大きなボトルネックとなります．
そしてそんなレガシーコードに頭を抱える時間が1日の大半を占めるようになったとき，私達はリファクタリングという選択肢を考えはじめるのかもしれません．

本稿では約3年に渡る大規模なリファクタリングを入社直後に引き継いだ筆者の体験を基に，直面した課題と解決策，および安全にリファクタリングを進めるために意識したコーディングスタイルを示します．
また，引き継いだ実装から見えてきた，スプラウトクラス等のリファクタリング手法の有用性についても考察します．
考察や説明には、iOSエンジニアに馴染み深いSwiftのコードやリファクタリングに関する文献を適宜引用します。

なお，具体的には以下のようなトピックについて執筆する予定です．
【トピックプラン】

• レガシーコードはクラッシュしてくれてサンキュー．
• リファクタリング中に機能追加が必要！考えられる手段。
• 宗教戦争？privateなメソッドの自動テストを書きたいときにどうすればよいか．
• 解体したい神クラス，でもテストが書けないから下手な修正はできない．そんなときの折衷案．