小〜中規模のWebサービスを数年運用して学んだことをまとめていきます。

ブログや勉強会などで大規模なWebサービス運用に関する話は比較的入手しやすい一方で、小〜中規模のWebサービスついての情報はあまりまとまってないなぁと何となく感じてました。

フリーランスになってから、掛け持ちで色々なプロジェクトに関わってきたのですが、3年以上に渡ってWebサービスの開発＆運用を通じて、色々悩んだり学んだことが多くあります。

世の中に自分と同じような境遇の人が少なからずいるのかなと思い、そういう人に少しでも役に立てればと思って、これから数回に分けて学んだことをまとめていきます。

前提として

自分が関わってきたWebサービスの規模や開発体制とか簡単にまとめておきます。

大きく分けると

という形に整理できそうです。

Webサービスの運用に関するテーマに関連することは、知識転用を上手く行えると思ってるので、なるべくこちらが手厚くなるように出来る限り情報を整理してまとめていく予定です。

※ ちなみに、1年ほど前から並行して行ってるお仕事がLaravel/PHPと全く異なる技術スタックなのですが、それまでに学んできたWebサービスの運用に関する色々なことがとても役に立ってます。

テストがほとんどなかった状況で、チーム全体でテスト書く習慣が身につくまでの課程
ドキュメンテーションどうしてきたか？
- 社内のドキュメント管理のツール見たら3年で159個書いた。
- これは今回のプロジェクトに限定しないけど、前任者がいたけど情報が更新されてない/うまく分類されなかったり、そもそも全く手付かずの状況で、何をどんな順番でまとめてきたのか
過去一度もbundle updateしてないプロジェクトでどこから手を付けるべきか
RailsEngine採用したけどどうだったか？
- 以下2点考慮して採用
  - 既存の処理を残しつつ新しい仕組みを取り入れたい要望（＝途中から多言語対応）に応えるために採用
  - 既存のView/JavaScript/CSSのメンテナンスが大変だったのでキレイにしたかった

決済処理でこれをやっておかないと苦労すること
とにかく大変なメール送信まわり
- 想定チーム規模だとSendGridのようなSaaSを使うと思うけど、その中で自分たちで考えないといけないこと
DBの寿命はアプリより長いを実感したあれこれ
- 何も考えない statusカラムの乱発による弊害、SQL アンチパターンにある過去の状態がなくなることの弊害、その他に細かい部分含めて色々悩んでる。
DBのMigrationのコードレビューで意識するべきこと
- カジュアルに index作成すると、痛い目に合う、実際のSQLを想定して、実行計画とかを一応チェックするのが無難、などなど）
多言語対応固有の問題
- チート対策的なこと（qq.comを利用した会員登録してきた等）
- 途中から多言語対応を始めた場合の苦労とか