最初からマイクロサービスとして実装する事はないだろうし、メリットもほとんどないとは思う。ただし、マイクロサービス化しやすいモノリスの構成というものはあると思うし、逆にマイクロサービスにスイッチしにくくなるような悪手やアンチパターンのようなものはあると思う。僕の趣向としては、別にマイクロサービス押しでも何でもなくて、動けば何でも良し精神で生きている。だから結構歪な状態になったりするし、それによって後から参加した人に冷やかな視線を向けられることもしばしばある。Emacsを使っていると、グローバルにいろんなものがあるというのも、あながち悪いことじゃないよなとも思うし、実装の細かな話にはあまり興味もない。それは、その時々の状況やそれを扱う人やチームによって、正解が変化するからだと思う。

例えば関数の共通化も、正直本当にそれをするべきなのか疑問に感じることがよくある。特にIOに絡むような処理を含んだ、サービス的な関数を共通化した場合、泥だんご状態で何が起きるのかさっぱりわからないし、パフォーマンスで問題がでた時に最適化もしにくい関数が出来上がることがよくある。その処理を修正する時に1箇所直せば良い状態にはできるかもしれないが、それって本当にそんなに大事な事なんだろうか。石に焼いたり、問題があった場合にリコールが発生するなど、リカバリが難しい場合は、そういった共通化にも意味があるかもしれない。一方でWebシステムのような修正と再デプロイがしやすい環境で、またシステムを取り巻く状況が変化しやすいコードでは、パフォーマンス改善などの足を引っ張ることになることもあるし、影響範囲が明確にならず確認が漏れてしまったり、関数のインターフェイスに関わるような修正をしたい場合にも、怖くてできないという状況になりかねない。

デザインパターンや設計論のようなものを一生懸命勉強してた時期があって、その頃は良くある設計方法に当てはめてシステムを作ることが良いことだと考えてた。バカバカしいと感じるかもしれないけれど、大真面目に本当にそう考えていた。こういう時は、このパターンを使って実装する時だという感じで適応した。そういった方法が良い時もある。でも常にそうではない。むしろそうやった実装によって足を引っ張られた事が結構あった気がする。

呼び出しの深い位置でIOが実行される時、そのコードをよく知らない人は、そのIOをどうやって把握できるんだろうか。コードを辿って最後まで読むのだろうか。ダックタイピングされていたり、重めの抽象化をされていた場合、きっと処理を見失うと思う。そうだったら、ベタ書きのほうがマシだと思うこともあるだろうという話だ。ベタ書き、コピペは本当に悪なのか、僕はそれらは人や状況に寄ると思うんだ。

ただ、大切だなと思うのは、振り返りを頻繁に継続的に頻繁に行って、現状と照し合せて、本当にこれで良いのかという事を考える事、その機会を作ることだと思う。一発でバシっと良い感じにできた試しはないから、継続して取り組む事が大事なんじゃないかなぁと思う。