化石みたいになったカスタマイズ、つらい
もっと長く運営しているシステムをお守りしている方には8年程度と怒られるかもしれないですが、これくらい経つともう何のためのカスタマイズかわからないコードが割とあります。
こういうのはバグの温床になったりQAのコストを増加させたりしますし、何なら重要なビジネスロジックの中に複雑にカスタムコードが入り込んでいたりするので摘出するのも大変です。
SaaSの王様Salesforceの話ですが、初期に超王手金融クライアントのためにカスタマイズをしてしまって、その後そのカスタマイズによってインシデントを引き起こしてこれじゃダメだとなってAPIを提供するプラットフォーム化を進めることになったという話があります。プラットフォーム化した今でもそのカスタマイズコードは切り離せずに残ってしまっているそうですw
(参照→ https://open.spotify.com/episode/58TPAKYpVVkOBWlwQuFQF7)
今日はそんなカスタムつらいよ話をします。
遭遇したカスタマイズのパターン
controllerやviewにif-elseが連なっている
安直でわかりやすいのでさほど厄介ではないだろうか。カスタマイズを認知するのも標準機能化するのも摘出するのも容易と思われる。
しかしfat controller拒絶症のエンジニアがいたら発狂してしまうので注意。
メールアドレスなどのハードコード
これもわかりやすいので厄介ではないはず。
enumにカスタマイズ用の値が定義されている
テストが漏れていると危ない。
ページファイルがクライアントごとに分かれている
ファイルごと分かれているので、改修時には見落としてしまってバグになりがち。
機能ごと特定のクライアントしか使ってない(または使えないようになっている)
そもそもカスタマイズであることが忘れられていく。この機能誰が使ってるの？と言って削除してしまうと後で怒られてインシデントになりがち。(自分が経験したわけではないです、一応。。)
他にも思い出せそうですが胃が痛くなってきたのでやめておきます。もっと別なパターンがあったら教えてください。
なぜカスタマイズが混入してしまうのか
サービスを方向転換することがあればどうしても当初の設計に無理が生じるためと考えます。
自分の経験だと、最初はSaaSでもなんでもなかった→2社が共同利用するようになった→マルチテナント展開するようになったという経緯で成長したサービスでしたが、マルチテナント化の最終的な意思決定をするまでの間に(後から見れば)カスタマイズになるコードが混入することになってしまいました。
カスタマイズに向きあうための考え方
- 全て除去しよう、負債を返済しようと思わないこと
- 上記Salesforceの話しかり、影響度的に摘出不可能なものもある
- 抱えてしまった負債は仕方ないと考えて、むしろこれと一生付き合う覚悟を持つ
- ただしカスタマイズを全て一覧化して把握する努力はする
- カスタマイズはバグの温床なので、それを踏まえてテスト設計をする