開発スピードの減速と再加速
•
1 like•763 views
みんなのウェディングではPerlの独自フレームワークのMobaSiFからRuby on Railsへの移行を進めています。 移行前の改善活動から最終的に移行に向けて動き出すまでの経過のおはなしです。
More Related Content
Viewers also liked
Viewers also liked (19)
Recently uploaded
Recently uploaded (8)
開発スピードの減速と再加速
- 29. 💪
Editor's Notes
- 今日は寒い中、勉強会に参加してくれてありがとうございますm(_ _)m 「開発スピードの減速と再加速」というタイトルで話させてもらいたいと思います。
- 工藤ともうします。 こんななりですが、一応結婚してて、結婚式は楽しんだクチ。 アイコンの通りでねこ好きで通っております。 みんなのウェディングもだいぶ長くなりまして、はや7年。 なんだか知らないうちに、社員番号が前から五番目になってしまいました。
- ginza.rbという地域Rubyコミュニティもやってたりします。 Railsセキュリティチェックリストについて、2/21にみんなのウェディングのオフィスで 頼りない自分を心配してくれてか、いっしょにやっているwillnet氏やy-yagi氏も顔を出してくれてたり、勉強会に足を運んでくれた方もたくさん。 大変ありがたいことですm(_ _)m 発表とか全然慣れていないんですが、少しリラックスして話せるかもしれません。
- 弊社はみんなのウェディングという、結婚式場紹介口コミサイトを運営しています。
- 結婚式、披露宴は一度に多くの人数を呼ぶので、人数分の飲み物食べ物はもちろん、招待客が入れる場所、出し物の準備をするバックヤードがあったり、準備を円滑にしたり当日招待客のみなさんがゆっくりできるようにするスタッフが必要なので、思った以上にお金がかかるし、やりなおしも効きません。 そんな結婚式披露宴ですが、思ったほど身の回りに経験者がいないと思いませんか？ みんなのウェディングでは結婚式場での実際の口コミを経験者からあつめて提供し、これから行う花嫁花婿の結婚式当日をより大切な日にしてもらうためのサービスです。 もちろん、結婚式の関係者の結婚式場等のクライアントにも参画してもらい、それぞれの式場の情報を提供してもらったりしています。
- 2008年にDeNAの社内ベンチャーとしてサービスを開始してから、2010年に分社化、おかげさまで2016年9月は460万ユニークブラウザに到達しています。 厚生労働省の平成28年度(2016)の「婚姻に関する統計」によれば、平成27年は今件数は63万5千組。なにかしらの形で見てもらえているサービスになっていると思います。
- DeNA生まれのみんなのウェディング。モバゲーを支えていたケータイサイト向けのWebアプリケーションフレームワークのMobaSiFを使って開発が始まりました。ケータイ3キャリアの機種でよろしくページを表示できたりします。みんなのウェディングでは2015年12月までケータイをサポートしていたので、大変お世話になりました。 MobaSiFはPerlと若干のCで書かれていて、 ApacheとMySQLをあわせて使います。当時のデファクトスタンダードでした。 Mobasif表示させることのみにフォーカスしており、それ以外の機能は持っていないので、イマドキのフレームワークに比べて非常に薄く、見通しが良いです。 SourceForgeで公開されているMobaSiFのサンプルのように、MobaSiFを利用するには、フレームワークを設置したディレクトリにそのままアプリケーションを構築していきます。
- そのような感じなので、フレームワークとアプリケーションの境界が薄いです。フレームワークのコードにサービス独自の処理を記述し、アプリケーション化していきます。 例えば、ログイン処理とか計測の処理とか…。 アプリケーション化してしまったフレームワーク、バージョンアップをどうしましょう？ 新バージョンのフレームワークと、アプリケーションの融合しているフレームワークの差分をどうやって反映するには、新バージョンのフレームワークの変更の意味をわかった挙句、それを手作業でアプリケーションに反映していかなくてはいけないはずです…。 よほど強い動機がないとできそうにありません…。
- フレームワークとして推奨しているディレクトリ構成はほとんどありません。非常にPerlっぽいかと…。 MobaSiFはオープンソースとして公開されましたが、それほどメジャーにまではなりませんでした。なので暗黙の流儀のようなものもあまり生まれなかったと思います。ですので社内の大雑把なルールしか最初はありませんでした。 それから、当時は仕事のスタイルとして一人一案件としてまるっと任されることが多かったです。 ユーザに便利に使ってほしいとの気持ちから、各案件ごとに便利になるように考え抜いて、結果的に案件ごとに少しずつ違うものを作ってきました。
- サービスを大きくしてユーザによりよく使ってもらおうと、次々にいろいろなことをやってきました。 あれやって、これやって…。 短時間で作り、コードの整理をする間もなく、すぐ次の施策に取り掛かる。 各ページで少しずつ違う仕様は、コピペを促して…。 その後、他ページへその仕様を反映するには、テストがないので影響が測れず調査に時間がかかる。「今回はこれでいいか…」が積り易いのは…書いていてお腹が痛いです。 コードのメンテナンスはユーザの便利さや売上そのものに直接反映されないので、うまく説明できずちゃんと交渉できなかったことが悔やまれます…。
- 徐々に真綿で首を締められるように苦しくなってきました。 ちょっとずつ違うコードがあちこちに散らばっているので、改修や機能追加をするたびにあちこちgrep。 修正漏れがないかいつも不安でリリースが怖い…。
- さすがに辛くなってきたので、状況を改善すべくいろいろ試してきました。 テスト。seleniumとかcasperを試したけれど、各人の準備が大変なことと、強く推奨するまでしなかったので、普及には至りませんでした。 コーディング規約。レビューのときに人力でチェックしてました。違反してても見逃すとそのままマージされちゃいます。 モデル。基本的なdbアクセスをコードを書かないでできるようにしたりする社内ライブラリが作られ、新規機能で利用され始めました。 sass。今まで素のcssで書いていましたが、パーツの共通化をしていきたくて導入しました。gulpによってある程度の自動化がサポートされています。
- いろいろなことを試しはしましたが、微妙に手作業が残ったり、そもそも難しかったりで、大幅な改善までには至りませんでした。 …思い切って、フレームワークの変更を行ってしまおう。そんなふうになりました。
- Railsはみんな知っての通りですよね。 Rubyで書かれたWebアプリケーションフレームワークで、フルスタックで… テストとかSassとか、気の利いたものがひとつになっています。 一番大きいのは、利用者数が多く、日本語でも情報が得やすいところでしょうか。
- 移行するのは決めたけれど、さまざまな不安が…。 みんなのウェディングにはびっくりするくらいページがあります。どれくらいかかるんだろう？ もし移行を始めたら、機能追加や改修は続けられないのでしょうか？ というか、そもそもRails開発経験者が少ない…。 Railsはデータベースの作り方が全然違うじゃない…。 Railsは設定より規約。規約にまちがいなく沿ってないんだけど大丈夫なのか…。
- どれくらいかかるかは始めてみないとわからないので、ひとまず置いておいて…。 1ページずつできれば、Rails移行と同時にできるのでは…。 …ということで、前にreverse proxyとしてnginxを置き、Railsで表示できるようになったものだけRails側のサーバ、基本的にはMobasifのサーバに向けるようにしています。 こうすることで、指定したURLだけ、Rails側のページが表示されるようになりました。
- 社内で、Railsを使った開発をしたことのあるメンバーが3人しかいません…。
- サービスの成長自体は必須なので、最初はRails経験者達でRails移行チームを編成、ほとんどのメンバーはそのままPerlで開発していました。 いくつかのページを移行し終えて、ノウハウがたまり、開発の基盤が固まってきたころに、全エンジニアがPerl/Railsを問わず対応するようにしました。
- データベースの作り方が全然違う件については…。 普通にRailsが対応していて、命名ルールの上書きができ、テーブル名やプライマリキーをよろしく設定できました。
- ということで始めてみたんですが…。 先のほうで問題にしていた、似ているけど少しずつ違うコードがいっぱい。 どのコードが正しいかわかんないし、全部調べてまわるのにとても時間がかかっていました。
- 進捗が思った以上に悪く、悩んでいたのですが…。 あまり歴史を紐解くのに時間が掛かる場合には、開き直って、正しいと思うように作って、識者に確認してもらうようにしました。
- 昔と違って今は、テストを支援するツールがたくさんあります。 大きなWebアプリケーションであるのはわかりきっているので、何かしら変更したらどこに影響が出るか不安になることは多々ありそうです。 なので、移行するものについては必ずテストは書くようにしています。
- また、テストは書くだけではなく、ちゃんと使っていっています。 githubを使っているのですが、githubへプルリクエストを作ったり、プッシュしたりしたときには自動でテストが回るようになっています。当然、失敗だったときにはマージできません。 プルリクエストを誰かにレビューしてもらって、かつテストがOKだったらマージします。 masterにマージしたとき、やはり同様に自動でテストが行われ、OKだったらステージング環境に自動でリリースされます。 テストが万が一NGになっていると、ステージングへのリリースはできなくなります。 本番へのリリースは、ステージング環境へリリースされたリビジョンを指定して行います。 強制力を多少持たせているために、テストは常にグリーンを保つようになっていると思います。
- テストを揃えながら移行作業が進んできました。 Railsのコードが大きくなってきて、テストも順調に増えてきて、テスト完了に時間が掛かるようになってきました。10分を超えるくらい。
- テストがやりにくくてテストが疎かになってはあまり意味がありません…。 テスト実行を並列化させて、完了時間を早くしました。 （基盤のチームに感謝です…。）
- そのうちに、デザイナ・エンジニア全員がRailsでコードを書くようになり…。 テスト実行のために行列になることが多々起きるようになりました。 下手をすると、一時間以上待つことも…。
- テストがやりにくくてテストが疎かになってはあまり意味がありません…。 テスト実行を2系統に変えました。 テスト完了までの時間は掛かるようになりましたが、テスト実行を待つことがほとんどなくなったので、最終的に早くなりました。 ただ、これは少し問題があって、マージ後にテストが通ったらステージング環境にリリースされるのですが、タイミングによって順番が前後することがあります。 とはいえ、ほとんど起きないので、今はこのまま。 次の人がマージされるのを待つか、テストの再実行でしのいでいます。
- アプリケーションの移行の道筋は立ち、ぼちぼち進んでいるのですが… まだ問題は残っています。 採番テーブル。高負荷ケータイゲーム向けのノウハウでできていたので、複数DBでうまく動くようになのかな…？ みんなのウェディングはそこまで高負荷になったりもしないので、余計な機構は取り除きたいと思っています。 データベースの文字コードがShift JISです。 ケータイの絵文字があったから…。今後はUTF-8に変えたいと思っていますが、まだ波乱がありそう…。
- 青がMobaSiFの追加行数、緑が削除行数です。 2015年から登場している黄色とオレンジはRailsの追加行数と削除行数です。 MobaSiFのほうは追加に比べて削除行数がだいぶ少ないですね…。継ぎ足しでコードを書いてる感が見えてきます。 Railsのほうは2016年は追加に対して削除が半分程度と、追加だけでなく削除も多くの割合で行なっていけていることが見えます。コード行数もだいぶ少なくなってそうで、効率的に書けるようになったとも言えそうです。
- このグラフはコミット回数です。青がMobaSiF、緑がRailsです。 2016年のコミット回数は2015年より2016年のほうが総じて増えています。 コード行数もだいぶ少なくなってそうで、効率的に書けるようになったとも言えそうです。
- コードの追加行数がコミット数との比べると、だいぶ減りました。しかもここにはテストのコード行数も入っています。 総コミット数が増えたので、すぐ作れるすぐ直せるようになったといってもいいですよね。 追加行数と削除行数の比率を見ると、Railsに移行している部分に関しては2:1くらいでした。 削除しやすくなっていそうです。
- 先に出てきた、利用者数のグラフです。 折れ線は移動平均です。 グラフ下の線で、青色のものはMobaSiF、赤色のものはRailsのシステムが存在している期間です。 2014年9月くらいまで、よいぐあいに上がってきてましたが、その後、伸びが少し緩やかになり…。 2015年9月くらいから少し傾きが出てきた感じにみえませんか。 社内全体で変わろうとし始めた時期で、ちょうどそのあたりからRails化を始めています。 再加速したと言わせてもらってもかまわないでしょうか？ それから、もうひとつ。 300万ユニークブラウザまでのひとに使ってもらえるようにサービスを支えてきたのは、MobaSiFの上に作られたシステムです。 レガシーレガシーだとつい思ってしまいがち、コードを覗けば、過去の自分のコードで苦い顔をしたくなるものもたくさんあります…。 ですが、過去を思いかえせば、そのとき持てる道具とそのときのメンバーで精一杯やりました。 なるべく早く、笑顔で送ってやりたいと思います。
- すみません。少し感傷にふけってしまいましたが…。 サービスが当たって、ユーザに使ってもらえるようになると、長い時間サービスを継続することになります。 長い時間サービスを運用していると、サービスで利用できていないけど、サービスを支えるために使えそうな周辺技術も進化してきます。 どこかで開発が遅くなってきたな楽しくないなと感じたら、ちょっと腰を据えて周りを見渡してもいいかもしれません。 突飛な技術ではなく既存のメジャーな技術だけでも、困っていることを解決していけることが多いです。 ユーザに支持されていて、自分も好きなサービスを、自分の好きなメンバーとともに楽しく開発しつづけられるよう、努めていけたらな、と思っています。