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

10歳の minne から、これから長く続くプロダクトを作るすべての人へ

10歳の minne から、これから長く続くプロダクトを作るすべての人へ

tsumichan

July 27, 2022
Tweet

More Decks by tsumichan

Other Decks in Programming

Transcript

  1. GMOペパボ株式会社 minne事業部 2 自己紹介 市岡 なつみ tsumichan • 2018年4月 新卒入社

    • minne の バックエンド開発を担当しています • 寝ること、もふもふしたもの、お寿司🍣が好き • ねこを飼うのが夢 • マイブームはオクラです • Twitter : @tsummichan
  2. 7 • 最近つらいのは検索サーバーへの同期と退会処理 • 検索サーバー(Elasticsearch)への作品情報を reindex するとタイムアウトするので、根気よくリトラ イしている • サーバーのスペックを上げたり並列度を上げるなどして対策する予定

    • 退会時にユーザーに紐づくお気に入りレコードを削除するが、お気に入りが多いとタイムアウトしてし まうのでユーザー体験に影響が出ている • お気に入りは user に対し has_many で紐付いていて、 dependent: delete_all が設定されている • お気に入り以外にもいろいろ削除しているが、必要最低限のもの以外は非同期処理化していく予定 1. シンプルにデータ量が増えて大変になった 10年経ってつらいところ
  3. 8 2. 意図がわからない設計や命名がある 10年経ってつらいところ • 「このカラム消したいなあ…なんのために作ったんだっけ?」 「これなんでこういう仕組みになってるの?」→作られた当時にいた人が退職していて誰もわからない… • pull request

    やコミットメッセージに ”なぜそうしたのか”が書かれていない • GitHub から GitHub Enterprise へ移行した時に昔の issue, PR の画像などが一部消滅した • pull request やコミットメッセージに Why を書くようにチームで取り組み中 • 改修途中で力尽きたものがある • デザインの刷新時に、ユーザーの管理ページが /user にあったが新しく /account に作り、徐々に /account の方へ移行する予定だった • 一部機能はまだ /user に取り残されていて、 controller なども user と account の2つが存在して いる
  4. 9 2. 意図がわからない設計や命名がある 10年経ってつらいところ • プロダクトビジョンが変わったが、内部の設計や命名はそのままになっている • 昔はハンドメイド作品を売買するプラットフォームではなく、ハンドメイド作品を展示するサービスだっ た •

    minne の作家のトップページは昔「ギャラリー」と呼ばれていたが今は「ショップ」になった • ユーザーに見えるオモテ部分はアップデートされていても、ソースコード(クラス名など)はまだそのままになって いる
  5. 10 3. 保守コストが高い 10年経ってつらいところ • 機能の数が多すぎて保守やメンテナンスの手が回らない • あまり使われてない機能も消さずに残されている • 利用率とメンテナンスコストを天秤にかけて、コストのほうが重ければ消していきたい

    • 統一されていないアーキテクチャ・設計がある • これについては何もできていません … 😥アドバイスお待ちしています • deprecated なものが存在している • Ruby, Rails のバージョンアップに伴って deprecated になったメソッドや記法とか • Controller Spec, CoffeeScript とか • Rubocop を導入し、ボーイスカウトルールでできる範囲から徐々に書き換えているところ
  6. 12 1. 古すぎてどうしようもないみたいなライブラリなどは少ない※ • ※全く無いとは言っていない • ただただ先人たちがしっかりアップデートしたり保守を頑張ってくれたおかげ • 長い間メンテナンスされていない gem

    を使っていたりはするので、いつ動かなくなるかわからないと いう危険性はあり、それをどうするのかはこれからの課題 • アップデートを後回しにして溜めてはいけない(戒め) 10年経ってよいところ
  7. 18 プロダクトを作り直したり仕組みを変えたりしないといけなくなる日が必ず来る • プロダクトが大きくなると、その状態に合った仕組みにしないといけない • 今はイケてない作りでも、作った当時はそれが最良のやり方であったはずなので、「これイケてなさすぎ るだろ、誰が作ったんだよーw」とか言えない、言っちゃいけない… • 将来のためにも私達も常に最良のやり方で作ろう •

    minne では、過去に仕組みを変えることでユーザー体験を改善ができる機会があったけど、他にやるこ とがあってそこにコストをかけられず、妥協してしまったことがある • 「しっかり対応していればもっとユーザーが使いやすくできたかも」 • 規模が大きくなるほど仕組み変えるのが大変になるので、サービスの規模がそこまで大きくなくて、 作り変えるのを迷ってるひとがいたらやったほうがいい!!! これから長く続くサービスを作るすべての人へ