Design PatternsDấu hiệu lạm dụng pattern:
- Interface chỉ có một implementation và tồn tại đã lâu, không có kế hoạch thêm cái thứ hai.
- Factory tạo ra object mà new là đủ; abstract factory cho một nhà cung cấp duy nhất.
- Chuỗi gián tiếp dài: controller → facade → service → manager → helper → repository, mỗi lớp chỉ chuyển tiếp tham số.
- Tên file toàn hậu tố pattern (XxxStrategyFactoryProvider) nhưng không có tên nào nói về nghiệp vụ.
- Sửa một quy tắc nghiệp vụ nhỏ phải mở 5-6 file.
Pattern là giải pháp cho vấn đề đã xuất hiện, không phải tiêu chuẩn chất lượng để áp trước. Áp khi chưa có vấn đề thì bạn trả giá bằng độ phức tạp mà không nhận được tính linh hoạt tương ứng.
Cải thiện dần thay vì viết lại:
- Viết lại toàn bộ gần như luôn thất bại ở mức chi phí: trong lúc đó hệ thống cũ vẫn phải chạy và vẫn nhận yêu cầu mới, nên bạn phải bảo trì hai hệ thống cùng lúc.
- Cách bền hơn là Strangler Fig: dựng phần mới bên cạnh phần cũ, chuyển từng luồng qua sau một lớp định tuyến, chỉ xóa code cũ khi luồng cuối cùng đã chuyển xong. Mỗi bước đều có thể dừng lại và vẫn ở trạng thái hoạt động được.
- Trước khi đụng vào một vùng code, phủ test ở ranh giới của nó (đầu vào/đầu ra), để refactor có lưới an toàn.
- Ưu tiên vùng vừa hay đổi vừa hay lỗi; vùng phức tạp nhưng nhiều năm không ai sửa thì để yên.
- Gỡ bớt một lớp gián tiếp thừa cũng là refactor hợp lệ. Bỏ pattern không cần thiết là cải thiện, không phải thụt lùi.