シンプルイズベスト
こんにちは。年長エンジニアです。
毎年映画館でだいたい12～13本ぐらい鑑賞してますが、今年はちょっと観たいと思うのが少ない感じです。
昨年末に今年の鑑賞候補を洗い出したいた時点では5～6本でした。現在は少しずつ増えて10本ぐらいにはなってますが。
アクション系と日常系が多いです。
ちなみにある程度映画を見る人は松〇系とか東〇系とかの会員になってた方がお得です。6回観たら１回無料になります。
個人的には松竹系の方がおススメで、6回観たら1回無料というのは同じですが、１回観たらクーポンが発行されて次回鑑賞時は割引になります。
よろしければ。
さて本題です。
混在システムはデメリットしかない
コードがスパゲティ状態というのは良く聞く話ですが、ここではもう少し引いてシステム全体でのお話です。
最初は１つの言語、１つのフレームワーク、同じ言語のAPIとシンプルな構成だったものが、月日を追う毎に進化という名のもとに多言語、多フレームワーク、多思想になってただでさえ規模が大きめのシステムなのに混在複雑化になり、改修作業や調査、バグ対応に大幅な工数がかかるようになり、進化なのか退化なのかって感じでメリットよりデメリットが多くなっています。
とあるシステムの話ですが、最初はPHPのsymfonyがメインでAPIも同じPHPというシンプルなものでした。
そのうちエンジニアからRubyが良さそうということで、まずAPIをRubyに置き換える流れで移行が始まり、やがてbizと言われるビジネスロジックもRuby側で行うことという流れになりました。
さらに今度はそのbizの一部がTypeScriptに。。
結局最終的にPHPの複数バージョンが混在、開発言語も場所によってPHP、Ruby、TypeScriptで言語によって開発ルールも異なるという見事な混在システムになってしまいました。
新しいものを導入した時に全体にやり切るのではなく、一部の機能に適用してあとはこれを参考に各担当部署でやってねという感じなので当然進むはずがなく、悪い言い方をすれば誰かの自己満足って感じです。
改修箇所によって言語もルールも違うので、当然開発工数も上がりますし求められるスキルも変わります。
新しい仕組みや良いなと思う技術は当然出てきますが、既存システムに適用させる（特にそれが長年稼働しているシステムであれば尚更）のであれば、やり切る覚悟を持って進めないと中途半端な混在状態になります。新しい仕組みや言語を導入するのであれば新規のシステムで試す方が良いです。
１つのシステム内で混在するよりは、システム別で分かれている方が遥かにマシです。
どちらかと言えば新しい仕組みや言語の導入よりも、言語やフレームワークのバージョンアップの方が重要であり、古いバージョンがだと実現されていなかったりで何十行も自前で書く必要があったりしますが、新バージョンだと1行で済んだりします。
混在システムは開発スピードも落ち機会損失にも繋がり、エンジニアの負荷上昇、さらにエンジニアを募集するスキル範囲が広くなるため集めにくくなります。
コードもシステムもシンプルが一番と思う今日この頃です。
共通処理の功罪
システム共通の関数を用意して、それを使えば効果的、修正もそこを直せば全体反映で簡単なんてのもありますが、システム図の横並びになる部分の共通化は経験上デメリットが多い印象です。
共通化は同系列の縦系に閉じておいた方が良く、広過ぎる共通化は結局分岐が入って意味が無いものになります。
１か所直せば良い⇒１か所修正すると広範囲に影響するってことです。
まぁ最初は縦系だったのに横のシステム改修の時に「あ、良いものがあるから使おう」って広がってしまうパターンかもですが。
現在関わっているシステムも広げ過ぎた共通処理があって、結局「この時はこうする」という分岐が入ってしまって、関係ないシステム側に影響していないかのテストが必要になり工数増加になっています。
共通化は縦系に閉じて、横に広げないようにしないとですね。例えそれが全く同じコードを複数箇所で持つことになってもです。
それでは～
