クックパッド開発者ブログスマートフォン用の表示で見るクックパッド開発者ブログ2015-12-10もう失敗しない!プロジェクト書きなおして、最高の開発環境を手に入れるちくしょう、プロジェクトまるごと書き直したい自分で作り始めたプロジェクトであっても、途中から相乗りしたプロジェクトであっても、誰もが一度は体験する気持ちではないでしょうか。私が携わっている「おいしい健康」も例外ではありません。プロジェクトを全て書き直したいと思う一方で、全てのコードを書き換えようとするアプローチは、これまで作ってきた見た目や機能、ビジネスロジックを再現しきれずに潰えてしまう。いう話しも良く聞きます。実は全て書き直したいのではなく、その大きな目的としては以下のようなモノがあるのではないでしょうか。シンプルな作りに変えたい不要なコードが重なり、動作が遅くなっているところを解消したい新しいライブラリ、新しい技術を取り込めるようにしたい今回は、このような目的を達成しつつ、プロジェクトの書き換えを行った私達の話をしたいと思います。コードべースの中に名前空間を分け、コードとしては本体事業と同居して開発を進めていました。他の記事でも紹介されている通り、非常に大きなRailsのプロジェクトです。プロダクトに背中を預けることができます。プロダクトをゼロから作り始める時、事前準備をさほどせずとも作り始められるところがメリットでもあります。コードベースに乗っていることによるデメリットが目立ち始めました。読み込みやモンキーパッチなどが多数あるコードベースを分けることだけにフォーカスする先ほどのデメリットを全て解決するには、新しく書き直し。判断してしまいそうですが、あまりに時間がかかりすぎてしまいます。事業スピードを止めず、かつ、2つ目までの課題をクリアするために、私達は1年半ほど前にコードベースの分離を行いました。関して「おいしい健康」関連のコードのみを残す。いうことを実施しています。コードベースを分けただけの作業がメインではありますが、テストやデプロイのフローが、cookpadとは別になったことにより、「おいしい健康」だけのテスト実行およびデプロイが行えるようになりました。プロジェクト分離での学び一部課題は残してしまうものの、一番の課題であるデプロイ周りの課題が解決されました。この作業自体は1人のエンジニアが1ヶ月程度で行えたものでした。期間的にも短く、「おいしい健康」に与えた変更も最小限ですみ、大きな混乱もなく、リリースすることができました。レールに乗ったRailsアプリケーションへ先ほどまでの話しで、デプロイ周りの課題は解決できたものの、整理しきれなかった多数のライブラリや、モンキーパッチにより、Railsを起動する時間、テストを実行する時間は長いままでした。コードベースを引き継いできたので、巨大なRailsアプリケーションを動かすために、レールから外れているところが目立ってきます。実行が(普通のRailsプロジェクトと比べると)遅い消しきれなかった使用していないライブラリが多数存在しいてる高速化の対策もあったが、cookpad本体に当てられるものが(当然)ほとんど新しいイケてるライブラリを見つけても導入が難しいこれらを解決することによる事業的なメリットは、短期的には見出しにくいものではありますが、長期的に見ると開発効率は格段に向上し、確実にプラスになります。第一弾の分離作業により時間が経ち、「おいしい健康」のプロダクトをより成長させようとするほど、いよいよレールに乗ったRailsへと書き換える機運が高まってきます。着手が遅くなればなるほど、書き換えも難しくなり、レガシーを引きずったまま開発することになることは目に見えているからです。フルスクラッチでは書き直さないこの段階で成し遂げたいことは以下の3つでした。乗ったRailsプロジェクトにすること使用していないライブラリの削除モンキーパッチを出来る限り無くすことこの3つだけを念頭に、作業を進めていきます。ロジックを移していき、既存のテストが通るように修正していきます。途中、クラスを分割したくなったり、リファクタリングをしたくなったりしても、まずはグッと堪え、ロジックの移動&テストを通過させることに集中します。あまりにもコードの最適化に脱線してしまうと、最後まで書き換えを完遂せずにプロジェクトが頓挫してしまうことを防ぐためです。:-)新しく生まれ変わるプロジェクトを愛でるキッカケにもなるので、ほんのりと脱線することはオススメでもあります。使用していないライブラリの削除、モンキーパッチを出来る限り無くすことどうしても、保守的に残してしまいがちなモンキーパッチやライブラリですが、まず一度全て消してしまいます。renderさせたときにエラーがでるようであれば、ライブラリを追加していきます。合わせて、最新のライブラリでも動作確認を行い、極力新しいものを使うよう心掛けます。モンキーパッチは、積極的に無くす方向に動き、難しければライブラリを探し、それでもダメなら、当てるという方向が良いかと思います。実際、我々のプロジェクトに対して当てられていたモンキーパッチは古いものが多く、現在では他のライブラリを用いることで代用可能だったのもがほとんどでした。なれば、いよいよ検証作業に入ります。いかんせん、ほぼ書き直したプロジェクトなので、テストがGreenでもきちんと動くかは不安です。使用し、本番に流れてくるリクエストを裏で書き換えたRailsの動いているサーバーにも流すようにしました。ユーザーには影響を与えないようにし、実際に頻繁にリクエストの来るところを中心に問題がないかを検証していきました。検証期間としては、1週間程度を設けましたが、ほとんど大きなエラーも出ず、リリースへの決心がつきました。安全にリリースするいざ、リリースするときには、問題があったらすぐに巻き戻せるよう、稼働中のサーバーに加え、新しいプロジェクトのサーバーを用意してもらい、ELBで一度にアクセスの向き先を切り替えるようにしました。実際の作業は事業部担当のエンジニアではなく、インフラ担当のエンジニアの方にやっていただきましたが、スムーズに切り替えが完了しました。今回は特に問題なく、巻き戻しも行いませんでしたが、今後同じようなことがあれば、この方法をとるのが安心かなと思っています。小規模にコードベースを書き直しするメリット冒頭にも述べた通り、ヘルスケアチームでは2度に渡り、コードベースの書き直しを行ってきました。どれも一度に全てを変えるものではなく、小規模に着実にリリースしていくような手法を取ってきました。このような方法は事業部側ともメリット/デメリットが握りやすく、期間も短くて済みます。それは、事業部としてもエンジニアとしてもモチベーションを保ちやすく、また効果も感じやすいものです。他にも幾つかのメリットが今回の取り組みでわかってきました。自分のプロジェクトの奥深い闇を理解できる自分たちが普段触っているプロジェクトがどのように動いているのか、深く理解することができます。メソッドがモンキーパッチにより同じ挙動をとるようになっていたのは、個人的にはすごく驚いたことの1つです。普段は触らないミドルウェアについても触ることができ、今後の開発スピードを一段とアップさせる要因になったかと思っています。モダンな開発手法に追従する気力がわいてくる合わせて、プロジェクトの構造を知れれば、ライブラリは何を使うべきか。バージョンアップしてよいものか。ある程度察しがついてくるようになります。Railsの新しいバージョンを試してみよう。フットワーク軽く、様々な技術的トライが行えるようになります。これらは、チームに活力を与え、メンバー全体の技術力の向上にも役立つものかと思っています。次回の書き直しも安心!小さなものでも成功体験が得られれば、次回どういう風に進めればよいか、イメージは湧きやすくなります。一度、プロジェクトをキレイにしたら、終わりではありません。1年後にはまた、イケてないポイントを見つけ、プロジェクトを書き直したくなることでしょう。その時にも、前回、今回のトライは確実に生きてきます。なってくれば、次回以降もコードベースの書き直しにトライすること、確実に成功させることにも価値が見いだせています。終わりに今後も定期的に、このような取り組みをやっていくつもりです。までぜひお声がけください!今回の記事が皆様のお役に立てることを願っています。10:00もう失敗しない!プロジェクト書きなおして、最高の開発環境を手に入れるTweet関連記事2019-03-05マイクロサービス化を支える継続的切り替え術こんにちはこんにちは。今日はモンキーパッチの話をします。こんにちは、投稿開発部エンジニアの芳賀です。既存...2016-03-29安心してRailsアップグレードを行うための工夫こんにちは。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。