まぁ、大体パターンはある。
いわゆる「勝ちに不思議の勝ちあり。負けに不思議の負けなし」ってやつ。
今の現場もそうで、どうしようかなー、ってなってるんだが。
「できるエンジニアはたくさんのサービスやフリーのライブラリを知っている」
的な浅薄な思い込みから、
「設計がカタログショッピングになっている」
ってのが、たぶんでかい。
まずサービスとかライブラリの評価から始めるんだよね。
仕様に書き出されてる単語を並べてググったり、AI叩いたり。
これの何が良くないのかって言ったら、「そのプロダクトに必要なコンセプトを深掘りしない」ので、個々の小さい処理に引きづられて複雑な構成を前提にしてしまうということと、その複雑な構成をフルにカバーできるさらに複雑でリッチなライブラリなりサービスを、業務経歴書に書けるって理由も大きく影響しつつ、選択して、プロダクトの必要な部分とその複雑な仕様の間を無理ぐり埋めることで、複雑な上に歪んだ、9割以上「間違えた」使い方を、プロダクトの基本部分の凸凹にピッタリと縫い付けてしまって、取り外しできなくしてしまうということの2点だ。
こいつは、DDDとは対極にある手法なんだが、なぜかDDDを採用してますって組織でよくみられる光景だったりする。
つまり、DDDすら、プロダクトのコンセプトを深掘りしないで、カタログ捲って目について、「こいつは業務経歴書に書ける！」ってんで表面的に採用して、大した理解もできないままチームの技術力とのギャップを無理ぐり埋めて誤魔化して、にっちもさっちも行かなくなる。
しばらくしたら炎上始めるから逃げる。
ってパターンよな。
できるエンジニアはたくさんのサービスやフリーのライブラリを知った上で、そのプロダクトに必要なコンセプトを深掘りして、徹底的に抽象化、簡素化して設計してるんです。
Sudoモデリングみたいな画面帳票駆動の権化みたいなうんこ手法なんて、やりません。
そもそも「たくさんのサービスやフリーのライブラリを知った」ってのも、諸元表とか機能表とか「表」や提供者の広告記事を誦じてるんじゃなく、どういう経緯で設計実装されていて、裏でどういう処理がされていて、どういう癖があるかを把握している、っていう点で、多分別物だったりする。
この辺り、やってる連中は同じことをやってると思い込んでるみたいだけど、やってること、「全く違います」。
だから炎上するんです。