Career & Non-TechTiêu chí của một phần nhỏ tốt: tự nó chạy được và merge được, không làm hỏng nhánh chính, và review trong khoảng 30 phút là hiểu hết.
Các cách chia thường dùng:
- Theo lát cắt dọc (vertical slice): mỗi phần đi hết từ API đến database cho một trường hợp nhỏ, thay vì cắt ngang theo tầng ("làm hết database trước, sau đó làm hết API") — cắt ngang khiến không có gì kiểm chứng được cho tới cuối.
- Tách phần chuẩn bị ra trước: đổi tên, di chuyển file, refactor mở đường đi riêng một PR. Trộn refactor lớn với thay đổi hành vi làm review không phân biệt nổi đâu là logic mới.
- Dùng feature flag để merge code chưa hoàn chỉnh nhưng đã tắt, tránh nhánh sống lâu và merge conflict.
- Tách theo trường hợp nghiệp vụ: luồng thành công trước, rồi tới các nhánh lỗi, rồi tới tối ưu.
Khi giao cho người khác, mỗi phần cần kèm đầu ra kỳ vọng và cách kiểm chứng: sửa file nào, thế nào là xong, test gì để biết đúng. Task được mô tả bằng "làm phần thanh toán" thì không ai nhận được.
Lợi ích thực tế: PR nhỏ được review nhanh hơn và bắt lỗi tốt hơn, dễ rollback, và giảm rủi ro khi một phần bị chặn.