Quyết định kiến trúc đắt thường là một lần viết lại không ai cần. Cửa hàng đã nhận đơn trên WordPress không an toàn hơn vì trang chủ chuyển sang framework mới hơn. Một sản phẩm chủ yếu là API và một bảng không rõ hơn vì tôi nhét nó vào cùng theme với cửa hàng. Tôi chọn stack đã giữ hành vi đó, và giữ ranh giới đủ sắc để một người vẫn nhìn sang bên kia.
Ở lại nơi việc kinh doanh đã sống
Nếu doanh thu là thanh toán WooCommerce, việc nằm cạnh lần thanh toán đó: theme, plugin tôi thực sự tin, máy chủ, thư, bản sao lưu. Chuyển danh mục sang một frontend riêng để stack trông mới là một dự án. Bản thân nó không sửa một mã khuyến mãi hay một webhook bị lỡ. Tôi kiên nhẫn hơn với một thay đổi PHP thường xuất tuần này hơn là một lần chuyển mà phần thưởng chỉ là vẻ ngoài.
Laravel có chỗ khi thứ đó là một ứng dụng, với luật riêng, hàng đợi riêng, trang quản trị riêng, và không nên bẻ thành các trang. Một đường ống nội dung có trần chi tiêu và bước người duyệt là loại ứng dụng đó. Một site tiếp thị thì không.
| Hệ thống vốn đã là | Tôi với tới | Tôi không với tới |
|---|---|---|
| Cửa hàng đang nhận đơn | WordPress, WooCommerce, và máy chủ quanh chúng | Viết lại để trang chủ thành một framework khác |
| Một ứng dụng có hàng đợi và trang quản trị | Laravel, hoặc Nest nếu phần còn lại của sản phẩm đã là TypeScript | Một đống plugin giả làm sản phẩm |
| Giao diện có kiểu mà bảng và API dùng chung | TypeScript, từ đầu đến cuối | Một ngôn ngữ thứ hai chỉ vì các nút |
| Lấy đoạn, chấm điểm, một dịch vụ nhỏ trên tài liệu | Python | Runtime PHP của cửa hàng, vì trung thành |
Một ngôn ngữ trong một sản phẩm, không phải suốt sự nghiệp
Trong một sản phẩm tôi muốn một ngôn ngữ chính, để thay đổi API và thay đổi màn hình là cùng một lần xem. Trong cả việc làm tôi không giả như mọi thứ là một ngôn ngữ. PHP, TypeScript và Python đều đang chạy production ở đây, có chủ đích. Sai là trộn chúng trong một đường yêu cầu vì mỗi lớp là sở thích của ai đó.
PostgreSQL khi dữ liệu có quan hệ và tôi muốn cơ sở dữ liệu cưỡng bức chúng. MySQL khi cửa hàng đã chạy nó và chuyển đi không phải việc. Redis cho hàng đợi hoặc bộ nhớ đệm, không làm nguồn sự thật thứ hai. Docker và một nginx nhàm khi cần mô tả được lần triển khai, không phải khi tôi muốn học một bộ điều phối.
Viết lại phải gọi tên sự cố mà nó bỏ đi
Tôi đòi một câu trước khi một framework mới được vào kế hoạch. Sự cố nào mà stack hiện tại không đóng được sẽ mất vì lần chuyển? Nếu câu nói về khẩu vị, tuyển người, hoặc một bài nói hội nghị, lần chuyển chờ. Nếu câu là “plugin thanh toán không diễn được quy tắc giá này, và tôi đã vá quanh nó hai lần”, đó là câu thật, và tôi vẫn tìm một miếng vá nhỏ hơn trước một mặt tiền mới. Miếng vá nhỏ hơn thường có ở đó.
Cùng bài thử ấy áp cho một dịch vụ tôi muốn thêm cạnh cửa hàng. Hàng đợi có lý khi một yêu cầu phải sống sót một lần thử lại. Một frontend riêng có lý khi hai máy khách, không phải một lập trình viên, cần cùng một API. Cơ sở dữ liệu mới gần như không bao giờ có lý trong cùng quý với một vấn đề độ tin cậy. Dữ liệu bạn đã có chính là hệ thống. Chuyển nó là một dự án riêng, với bản kê riêng, và nó không sửa mã khuyến mãi.
Tôi giữ được một cửa hàng và một dịch vụ bên cạnh vì chúng gặp nhau ở một mép đã ghi: một webhook, một hàng đợi, một bảng. Tôi không giữ được hệ thống mà mép là “hỏi người dựng phần đó”. Người đó phải là tôi, cả sau khi ra mắt. Công cụ mới phải trả tiền thuê. Nếu nó không bỏ một lần chuyển tay hoặc một lớp sự cố, đó là khẩu vị, và khẩu vị có thể chờ.
Chọn chồng công nghệ giữ sự cố kế tiếp trong một đầu. Cái mới phải thắng điều đó, không phải ngược lại.
