商売をすでに支えている構成を残す

高いアーキテクチャの決定は、たいてい誰も必要としていなかった書き直しです。WordPress で既に注文を受けている店は、ホームページが新しいフレームワークへ移っても安全にはなりません。主に API とボードである製品は、店と同じテーマへ押し込んでも明確にはなりません。振る舞いをすでに持っているスタックを選び、境界は一人がまだ向こう側を見られるほど鋭く保ちます。

商売がすでに住んでいる場所に留まる

売上が WooCommerce の購入なら、仕事はその購入の隣です。テーマ、本当に信頼するプラグイン、サーバー、メール、バックアップ。カタログを別のフロントエンドへ移してスタックを新しく見せるのはプロジェクトです。それだけでは、プロモコードや取りこぼした webhook の修正にはなりません。見栄えが成果の移行より、今週出る素朴な PHP の変更のほうに辛抱があります。

Laravel が場所を得るのは、それが独自の規則、独自のキュー、独自の管理を持つアプリケーションで、ページに曲げてはいけないときです。支出上限と人の承認があるコンテンツの流れは、その種のアプリケーションです。マーケティングサイトは違います。

一つの製品の中では一つの言語。キャリア全体ではない

一つの製品の中では主言語を一つにします。API の変更と画面の変更が同じレビューになるためです。仕事全体では、すべてが一つの言語だとは言いません。PHP、TypeScript、Python は、ここでは意図して本番にあります。間違いは、層ごとに誰かの好みだったからといって、一つのリクエスト経路の中で混ぜることです。

データに関係があり、データベースにそれを守らせたいときは PostgreSQL。店がすでに MySQL で動いていて、移すことが仕事でないときは MySQL。Redis はキューかキャッシュに使い、第二の正本にはしません。デプロイを説明しなければならないときに Docker と退屈な nginx を使い、オーケストレータを学びたいときではありません。

書き直しは、取り除く障害の名前を言わなければならない

新しいフレームワークを計画に入れる前に、一文を求めます。今のスタックが閉じられないどのインシデントが、移行で消えるのか。文が趣味、採用、会議の講演なら、移行は待ちます。文が「購入プラグインはこの価格規則を表せず、周りを二度補修した」なら、それは本物の文で、それでも新しい店先の前に、より小さい補修を探します。より小さい補修はたいていそこにあります。

店の横に足したくなるサービスにも、同じ試験を当てます。キューが正当なのは、リクエストが再送を生き延びなければならないときです。別のフロントエンドが正当なのは、一人の開発者ではなく二人のクライアントが同じ API を必要とするときです。新しいデータベースは、信頼性の問題と同じ四半期にはほとんど正当になりません。すでにあるデータがシステムです。移すことは独自の棚卸しを持つ別のプロジェクトで、プロモコードは直りません。

店と隣のサービスを一緒に持てるのは、文書になった縁で会うからです。webhook、キュー、表です。「その部分を作った人に聞け」が縁のシステムは持てません。その人は私でなければならず、公開のあともです。新しい道具は家賃を払います。引き継ぎか、ある種のインシデントを消さないなら趣味で、趣味は待てます。

次の障害を一つの頭の中に残す構成を選ぶ。新しさはそれに勝たなければならない。逆ではない。