「大規模アプリのリノベーション」というタイトルで発表させていただきました。speakerdeck.com大まかな内容としましては以下のようなものです。ドメイン知識を得るまずは現状のアプリケーションの解析からスタートします。実装済みの画面を洗い出し、現状を把握します。正しい名前付けを行います。ライブラリと設計を決定する次にライブラリ、設計を決定します。いったレイヤー分けを行っています。この設計につきましては様々な議論があるところかと思います。これが唯一無二のものであると主張するつもりは毛頭ありません。現状では、この設計でうまく開発していくことができています。必要なコードはスライドにすべて書いてありますので、興味のある方はぜひご覧ください。設計がある程度確定したら、サンプルアプリケーションを作成します。叩いてそれをリスト表示するといった流れを表した、小さなアプリケーションです。盛り込んでみるなどの試行錯誤もここで行っていました。設計に問題があれば、プルリクエストで修正します。その際、ドキュメントの修正も合わせて行います。次に設計をドキュメント化します。いつでも最新の設計情報を見れるように配慮します。することで設計をぶれないものとします。今後引き継ぎがあったとしてもドキュメントがあれば比較的スムーズに対処できるはずです。着手ドキュメント化が完了したら、実際にリファクタリングを進めていきます。作業の流れとしてはレイヤーの最も下の者から順番に進めていきます。コードの置き換えは必ずステップごとに行うようにします。用メソッドを生やす事が考えられます。インスタンスを受け取り、ゲッタ経由で必要なインスタンスを受け取れるようにしておきます。着手する時はまず見積もりを行うようにし、何時までに完了するのかを明確にします。見積もりをオーバした場合、なぜそうなったのかを分析し、改善して次のイテレーションに進みます。リリースリリースは1〜2週間毎に行うようにします。問題が発生したときに原因究明をやりやすくするためです。タスクの見積もりもこのリリースサイクルを基準に行われます。まとめこうしてみると、準備に相当な労力を割いている事がお分かりいただけるかと思います。実際に準備にはかなりの時間を掛けており、傍から見ると過剰にも映るかもしれません。大きなアプリケーションに手に入れるには、これぐらいの準備が必要なのだと思います。実際に綿密な準備をしたことによって、スムーズにリファクタリングを進めることができています。ドイメイン知識獲得や、設計の確定をチーム全員で行ったのも正解でした。みんなで模索した結果なので、誰もが自信を持って進めていくことができます。リノベーションはまだ道半ばなので、完了するまでこの方針が本当に正しかったのかは分かりませんが、きっとやり遂げられるのではと感じています。新しいコードベースをもとにして、今後のアプリの成長に繋げれていけたらなと思います。Ltd.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。