オイラと仕事している人は十分理解できてると思うし、恩恵を受けていると思うが、システムをやるなら、
上策：事前対策(設計/予防)
中策：根本対策(エラーの箇所のできるだけ上流での対策、自動復帰の仕組み、ミスしづらい(できない)仕組み)
下作：ログ出力、監視の強化、運用のマニュアル化(爆)、エラーの握りつぶし 🙄
困るのは、目に見えやすいのは下作であるということ。
目に見えやすいと言うことはつまり、「上司にアピールしやすい」ということ。
また、運用マニュアルが積み上がっていく、充実していくことが「成果」としてカウントされると言うこと。
FAQが積み上がっていくことを「成果」とするところがあったが、「FAQが積み上がっているのに、プロダクトを改善しようとしないのはただの怠慢。むしろFAQを減らすことこそがプロダクトの成長」と教えてもらって目から鱗が落ちたことがある。
それと同じで、複雑な運用マニュアルが増えると言うことは、「システムを改善しようとしない、ただの怠慢」であり、それを主導する人間は「システムにつくフジツボを大量養殖する大悪人」ってことだ。
そういう「やる気のある無能」は、まず最初に射殺すべきであって、決して英雄扱いするものではない。
だが、上策、中策は「一般人には目に見えないし、理解できないし、そうなってて然るべき状態と思われている」という点で、
マジで報われない
「パフォーマスは申し分ない」とか上から目線で言われて、殺意を抱く。
そんな感じ。
この2年、首がつながってるのは誰のおかげだと思ってるんだよ、と(流石にそろそろ詰み、投了の時間が近づいてきているけどw)。
まぁ、個人的なあれこれは置いておいて。
目の前の、今動いているシステムがボロボロである場合、まず影響範囲をできるだけ小さく囲い込むために、実行コンテキストやドメイン境界でソースを分離して、次にその分離単位で利用するサービスの最適化(データ移行)、ソースのDSL化(Rustの場合はProcMacroを使う。Excelなどで定義からソースを自動生成するなど)、オブジェクト指向化してミスしづらい仕組みに移行するという、中策を駆使することになる。
効率的な手順の問題もあるので、これが結構難しい。
故障中のジェット機を、修理しながら飛ばし続けるみたいな作業なので。
もちろん、0→1の、設計フェーズで大事なのは「大きく設計」することだ。
これは外せない。
というか、これが全て。
新しいサービスは小さく始めるのでは？
と聞かれることがよくあるのだが、大きくする気のないサービスならそもそも作るなと言いたい。
大きくなることを前提に設計して「小さく実装」することを「小さく始める」と言うのだ。
もちろん、最初から超大規模な、常時スタンバイのデータストアを使え、というわけでは、ない。
「そういうデータストアに移行できるように、手順などを用意しておいて」小さなデータストアを使うのが正しい。
これを間違えて、大して考えないでいきなり手元から実装を始めて、追加追加で全体像が掴めない、迷路のようなソースを何万行、何十万行と積み上げていって、身動きが取れなくなるプロダクトの多いこと多いこと。
そこでなんとか資金を都合して、「新バージョンに移行します。言語も最新のイケてるやつに変えます」といって、Webページのチュートリアルをコピペして拡張して、でまた追加追加で全体像が掴めない、迷路のようなソースを何万行、何十万行と積み上げていって、身動きが取れなくなるんだよね。
ソースが迷路化するのは、プログラミング言語やフレームワークのせいではない。
お前のせい。
ってことは自覚するべきやろうなぁ、と思う今日この頃。
わかんなかったら、手伝いに行くのもやぶさかではない。
ちょうどそろそろ手が空くので。