Fintechプロジェクトの「スパゲッティコード」の裏側
Goで書かれたあるFintechプロジェクトに参画した当初、私はそのコードベースを見て衝撃を受けました。プロジェクトは5人の開発者で1年以上運用されていましたが、決済処理、DB接続、通知送信のコードが複雑に絡み合い、まるでクモの巣のような状態でした。MomoやZaloPayといった新しい決済ゲートウェイを追加するたびに、開発者は何十行ものネストされたif-elseを必死にコピー＆ペーストしていました。
その弊害はすぐに現れました。コンポーネントが密結合（tight coupling）しているため、ユニットテストを書くことが苦行となりました。一度、通知モジュールの表示バグを修正しただけで、なぜか決済フロー全体がダウンしてしまったこともあります。これは、デザインパターンを軽視し、「Goはシンプルに書けば十分だ」と考えた代償でした。
なぜGoでもデザインパターンが必要なのか？
