Upgrade to Pro — share decks privately, control downloads, hide ads and more …

rsgt2022

yota
January 11, 2022
160

 rsgt2022

yota

January 11, 2022
Tweet

Transcript

  1. • 関わってきたサービスについて紹介 ◦ 共通の問題 • 読書メーターの事例 ◦ 進め方 ◦ 失敗

    ◦ 反省 • ニコニコ漫画の事例 ◦ 気をつけたこと ◦ どう良くなったか • まとめ 5 発表の流れ
  2. • ビジネスを継続的に改善していくための、安全で柔軟な変更が困難 ◦ 機能開発に時間がかかる ◦ 保守・運用で時間が奪われる ◦ セキュリティ上のリスクがある ◦ パフォーマンスなどのユーザ体験上の問題がある

    ◦ 課題に対応できる技術者が少ない ◦ ドキュメントやテストがほとんどない ◦ 開発に関わる周辺環境が整っていない ◦ etc これらを解決するためにリプレースをしたい ただし、リプレースにはリプレースの難しさがある 7 関わったレガシーシステムの共通の問題
  3. 1. サービスを触ってみて、仕様をドキュメントに書き起こす ◦ サービスについて知っている人が誰もいなかったので必要なことだった 2. リーダーがタスクをたくさん作って、開発者はタスクをたくさんこなす ◦ 見積もりもリーダーが行う 3. まとめて作って、一気にリリースする

    ◦ 作るものは決まっているはずなのでまとめて作る ◦ 古い見た目でイケテナイから見た目も変えてしまおう リプレースに夢を見過ぎて、1回のリプレースでなんでも解決しようとしていた 10 どのように進めたか すでに危険な臭いがしますね
  4. • 度重なる開発スケジュールの延長 ◦ 仕様洗い出しを仕切れていなかった、など ◦ 結果的に最初の計画からリリース日程は1年以上伸びた • 1年半以上何も世の中に貢献できていないという気持ち ◦ 実装しても実装してもリリースまでまだまだタスクがあるし、増える

    ◦ 関係者に疲弊感が溜まっていく ▪ 「とにかくリリースして解放されたい...」 そんな中でもなんとかリリースできるところまで辿り着いた 11 開発中何が起こったか ※良くなかった作り方の話はたくさんあるが、今回は割愛
  5. 結果、大失敗 • リリースした直後にパフォーマンスに大きな問題が発覚 • ユーザから見ると ◦ 数年何も改善されず放置されていたのに ◦ ある日突然慣れ親しんだUIから置き換わって ◦

    しかもまともに使えないくらいパフォーマンスが悪い 12 リリースしてどうなったか 今思えば本当に良くない進め方だったし、強く反省しています
  6. • リプレースしたシステム自体も徐々に負債になっていった ◦ 作って終わりではない ◦ その時の全力でプログラミングしても、得た知識を反映しないと負債になってしまう ◦ リリースして初めて得られる知識もある ▪ 一気にリリースする場合、

    得た知識をシステムに反映するには、全体を修正することになる • リファクタリングし続けることが大事 ◦ 知識を得て、その知識をプログラムに反映し続ける ▪ 継続的に、コードをcleanにし続ける ◦ 全体が小さいうちに、得た知識を反映させる方が楽 14 さらにその後に知ったこと
  7. たくさんのことを一度にするべきではない • ユーザが使える単位でリリースし、インクリメンタルにリプレースを進めていく • リリースして得た知識を、素早くシステムに反映させる ◦ 小さくリリースすると、反映も楽に行える ▪ 安心してリファクタリングできるようなテストを充実させよう •

    インフラやDBへの変更も起こりうる • 新卒3年目以内のメンバーだけで進めるには知識も経験も足りていなかった ◦ だからこそ、もっと学習しながら開発するべきだった もしもまたリプレースを担当することになる場合は、以上のことを基本としようと考えた 15 反省 まさかこんなに早くリプレースを再度担当することになるとは...
  8. • 読書メーターというサービスに関する知識や歴史を一気に得られた ◦ もし深い知識や経験を持った人が近くに居たら、 式年遷宮としてシステムリプレースを使えるのでは? ▪ 20年ごとに新しい社殿を造り、技術継承をする *1 > 20年という期間は、当時の寿命でも

    2度は遷宮に携わることができ、 初めて遷宮を経験する次世代の技術者へ 技術を継承していくのに合理的であるという理由 *1 『コラム 式年遷宮に見る技術継承と技術者確保』より *1: 諸説あり 16 良かったことも 遷宮について (https://www.isejingu.or.jp/sengu/aboutsengu.html)
  9. • ニコニコ静画(画像掲示板)とニコニコ静画(イラスト投稿サイト)の仕組みを 拡張して作られたサービスが、ニコニコ漫画 ◦ 企画が固まってないので、既存の仕組みでできるような感じで作って、 固まったらきれいにしようね ▪ きれいにする時間なんてない🚩 • 2019年に課金機能が生まれたことで”人間が対応できる複雑さの閾値を超えた”

    ◦ よくバグが発生していたが、エンジニアが運用でカバー ▪ 最終的に保守運用のみで時間が使われ、機能開発をできなくなっていった ▪ ここでリプレース欲が高まる • トラック係数1 ◦ 読書メーターの時と違って、サービスのことを深く知っている人がいて良かった... 19 ニコニコ漫画の問題点
  10. 利用者との対話を重視する • システム利用者と一緒にリリース順序を決める ◦ バグの致命さ/発生頻度 ◦ 運用負荷の高さ ◦ パフォーマンスの問題 ◦

    置き換えやすさ(どれくらい独立した機能か) ◦ etc • 先すぎる計画は詳細を決めない ◦ 直近1~2ヶ月分が詳細まで決まっている ◦ それ以降は優先度が決まっているくらい ▪ 優先度が変わってしまったり、詳細を忘れてしまったり、 そもそも作らなくて良くなることがある 22 小さく、機能ごとにリプレースする
  11. リプレースに関するリスクを低減させる • 従来挙動と新システム挙動を 切り替えられるようにしてもらう ◦ 一部のユーザだけ ◦ リクエストの◦% ◦ etc

    • 新しいシステムでエラーが発生したら ◦ レガシーシステムに処理を引き継いでもらう ◦ 失敗のログを出す 23 切り戻せるように利用者と協力する ストラングラーアプリケーショ ン:https://bliki-ja.github.io/StranglerApplication/ LoadBalancer LegacySystem DB NewSystem
  12. 自動でも手動でも、テストは大事 • 新規の機能によって既存機能は壊れていないか? ◦ 自動化されたビルドとテスト • ローカル環境で気付けなかった問題はないか? ◦ 開発環境での手動テストで手触り感を確認 •

    利用者にとって使いやすいか? ◦ 利用者によるレビュー • ピークタイムや急なアクセス増の時の挙動はおかしくないか?エラーは発生していないか? ◦ 監視システムを初期から導入 • etc 24 知識を得て、システムに素早く反映する わかった問題にはすぐ対応してきたよ
  13. • 新機能を実装し、リリースできるようになった ◦ 機能追加に対する安心感が生まれてきた • 古い複雑なコードがどんどん減っていってる ◦ ◦ まさしく“ストラングラー”って感じ •

    不要な仕様も整理されるようになった • 保守に追われた時間が減って、機能開発に時間を使えるようになった • オートスケールできる作りになって、運用コストが下がった 27 リプレース前と比べると?
  14. • レガシーシステムはコードが汚く見えるが、 そもそも仕様が複雑なのでコードも複雑になっていることがある ◦ リプレースしても結局複雑なままだったりする • あるはずのないデータに出会うことがある • 良い感じにモデリングと実装ができた、と思っても使えないことがある •

    リプレース中にも新機能追加の要望はどんどんやってくる • リプレースの初期は、普段あまり気にしないことを多く実装する必要がある • モックだらけのそのテスト意味あるの? • レイヤーごとに作るのはやめた方がいい • 取得系から作ると安全に知識を得やすい • ペアプロで会話を開発の中心に • ドキュメントは陳腐化を意識してADRを作る • TDDは強力 31 時間があったら話したいこと