비싼 아키텍처 결정은 대개 아무도 필요하지 않던 다시 쓰기입니다. WordPress에서 이미 주문을 받는 상점은 홈페이지가 더 새 프레임워크로 옮겨도 더 안전해지지 않습니다. 주로 API와 보드인 제품은 상점과 같은 테마에 밀어 넣어도 더 분명해지지 않습니다. 행동을 이미 쥐고 있는 스택을 고르고, 한 사람이 여전히 건너편을 볼 수 있을 만큼 경계를 날카롭게 둡니다.
사업이 이미 사는 곳에 머문다
매출이 WooCommerce 결제라면 일은 그 결제 옆에 있습니다. 테마, 정말로 믿는 플러그인, 서버, 메일, 백업입니다. 스택이 최신으로 보이게 카탈로그를 따로 프론트로 옮기는 것은 프로젝트입니다. 그 자체로 프로모 코드나 놓친 webhook의 고침은 아닙니다. 성과가 보기인 이전보다, 이번 주에 나가는 평범한 PHP 변경에 인내가 더 있습니다.
Laravel이 자리를 얻는 때는, 그것이 자기 규칙, 자기 큐, 자기 관리 화면을 가진 애플리케이션이고, 페이지로 구부리면 안 될 때입니다. 지출 한도와 사람 승인 단계가 있는 콘텐츠 파이프라인은 그런 애플리케이션입니다. 마케팅 사이트는 아닙니다.
| 시스템은 이미 | 손이 가는 것은 | 손이 가지 않는 것은 |
|---|---|---|
| 주문을 받는 가게 | WordPress, WooCommerce, 그 주변의 서버 | 홈을 다른 프레임워크로 만들려는 다시 쓰기 |
| 큐와 관리 화면이 있는 애플리케이션 | Laravel. 그 제품의 나머지가 이미 TypeScript면 Nest | 제품인 척하는 플러그인 더미 |
| 보드와 API가 나누는 타입이 있는 인터페이스 | TypeScript, 끝까지 | 버튼만을 위한 두 번째 언어 |
| 검색, 채점, 문서 위의 작은 서비스 | Python | 가게의 PHP 런타임, 충성 때문에 |
한 제품 안에서는 한 언어. 경력 전체가 아니다
한 제품 안에서는 주 언어를 하나로 둡니다. API의 변경과 화면의 변경이 같은 검토가 되게 하려는 것입니다. 일 전체에서는 모든 것이 한 언어인 척하지 않습니다. PHP, TypeScript, Python은 여기서 일부러 프로덕션에 있습니다. 실수는, 층마다 누군가의 취향이었다고 하나의 요청 경로 안에서 섞는 것입니다.
데이터에 관계가 있고 데이터베이스가 그것을 지키게 하고 싶을 때 PostgreSQL입니다. 상점이 이미 MySQL을 돌리고 옮기는 것이 일이 아니면 MySQL입니다. Redis는 큐나 캐시용이지, 두 번째 진실의 근원이 아닙니다. 배포를 설명해야 할 때 Docker와 지루한 nginx를 쓰고, 오케스트레이터를 배우고 싶을 때가 아닙니다.
다시 쓰기는 없애는 장애의 이름을 대야 한다
새 프레임워크가 계획에 들어가기 전에 한 문장을 요구합니다. 지금 스택이 닫지 못하는 어떤 사건이 이전 때문에 사라집니까. 문장이 취향, 채용, 학회 발표에 관한 것이면 이전은 기다립니다. 문장이 “결제 플러그인은 이 가격 규칙을 표현하지 못하고, 그 주위를 두 번 기웠다”이면 그것은 진짜 문장이고, 그래도 새 가게 앞보다 먼저 더 작은 기움을 찾습니다. 더 작은 기움은 대개 거기 있습니다.
상점 옆에 더하고 싶은 서비스에도 같은 시험을 댑니다. 큐가 정당한 때는 요청이 재시도를 견뎌야 할 때입니다. 따로 프론트가 정당한 때는 개발자 하나가 아니라 클라이언트 둘이 같은 API를 필요로 할 때입니다. 새 데이터베이스는 신뢰성 문제와 같은 분기에 거의 정당하지 않습니다. 이미 가진 데이터가 시스템입니다. 옮기는 것은 자기 목록이 있는 별도 프로젝트이고, 프로모 코드는 고치지 않습니다.
상점과 옆의 서비스를 함께 쥘 수 있는 것은, 적힌 가장자리에서 만나기 때문입니다. webhook, 큐, 표입니다. 가장자리가 “그 부분을 만든 사람에게 물어라”인 시스템은 쥘 수 없습니다. 그 사람은 저여야 하고, 출시 후에도 그렇습니다. 새 도구는 월세를 내야 합니다. 인수인계나 한 종류의 사건을 없애지 않으면 취향이고, 취향은 기다릴 수 있습니다.
다음 장애를 한 머릿속에 두는 스택을 고른다. 새로움이 그것을 이겨야 한다. 반대가 아니다.
