Refactor Decision Framework — Cách Frontend Lead Kiểm Soát Rủi Ro Refactor
Refactor Decision Framework — Cách Frontend Lead Kiểm Soát Rủi Ro Refactor
1. Tư duy chính của Frontend Lead trong case này
Vấn đề không phải là:
“Có nên refactor hay không?”
Mà là:
“Refactor này có phục vụ mục tiêu delivery hiện tại không, và có đủ kiểm soát regression không?”
Vì hiện tại khách hàng đang cần:
Speed of delivery
+ Feature correctness
+ Stability
+ Low regression risk
Nên mọi đề xuất refactor cần được đánh giá theo impact, không chỉ theo cảm giác “code cũ chưa đẹp”.
2. Diagram tổng quan
┌────────────────────────────┐
│ Member đề xuất refactor │
│ "Code cũ có thể tốt hơn" │
└──────────────┬─────────────┘
│
v
┌────────────────────────────┐
│ Frontend Lead không reject │
│ ngay, cũng không accept ngay│
└──────────────┬─────────────┘
│
v
┌────────────────────────────────────────┐
│ Hỏi lại bằng câu hỏi phân tích impact │
│ - Refactor phần nào? │
│ - Lý do business/technical là gì? │
│ - Flow nào bị ảnh hưởng? │
│ - Có test/regression plan chưa? │
└────────────────────┬───────────────────┘
│
v
┌────────────────────────────────────────┐
│ Đánh giá theo 4 tiêu chí │
├────────────────────────────────────────┤
│ 1. Có liên quan trực tiếp feature không?│
│ 2. Có giảm bug/risk ngay không? │
│ 3. Có đủ test để cover không? │
│ 4. Có làm trễ delivery không? │
└────────────────────┬───────────────────┘
│
┌────────────────────┴────────────────────┐
│ │
v v
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Nên refactor ngay │ │ Không nên refactor lúc này │
├──────────────────────────────┤ ├──────────────────────────────┤
│ - Logic đang gây bug │ │ - Chỉ vì code chưa đẹp │
│ - Feature mới phụ thuộc mạnh │ │ - Scope chưa rõ │
│ - Có test/regression đủ │ │ - Dễ ảnh hưởng nhiều flow │
│ - Impact nhỏ, kiểm soát được │ │ - Không có regression plan │
└──────────────┬───────────────┘ └──────────────┬───────────────┘
│ │
v v
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Refactor có kiểm soát │ │ Ghi nhận thành tech debt │
├──────────────────────────────┤ ├──────────────────────────────┤
│ - Small scope │ │ - Tạo follow-up ticket │
│ - Unit test │ │ - Document risk │
│ - Regression checklist │ │ - Ưu tiên sau delivery │
│ - Code review kỹ │ │ - Không block feature hiện tại│
└──────────────────────────────┘ └──────────────────────────────┘
3. Cách feedback cho member
Bạn không nên nói thẳng kiểu:
Logic của em gần đây chưa hợp lý nên anh không muốn refactor theo đề xuất của em.
Câu này dễ làm bạn ấy bị defensive.
Bạn nên chuyển sang cách nói dựa trên context, risk, evidence, decision.
Mẫu feedback nên dùng
Anh ghi nhận ý của em là phần code cũ có thể refactor để tốt hơn.
Đây là một góc nhìn tốt, vì mình không chỉ implement feature mà cũng nên quan tâm đến chất lượng code.
Tuy nhiên, ở giai đoạn hiện tại, khách hàng đang ưu tiên delivery nhanh nhưng vẫn phải ổn định.
Vì vậy, trước khi quyết định refactor, mình cần đánh giá rõ impact và regression risk.
Anh muốn mình tách rõ hai loại việc:
1. Nếu logic hiện tại đang trực tiếp gây bug, gây khó implement feature, hoặc nếu không refactor
thì feature mới dễ sai, thì mình có thể refactor trong scope nhỏ và có test/regression checklist.
2. Nếu refactor chủ yếu để code đẹp hơn, dễ đọc hơn, nhưng chưa ảnh hưởng trực tiếp đến feature
hiện tại, thì mình nên ghi nhận thành technical debt hoặc tạo follow-up ticket sau.
Em giúp anh làm rõ thêm:
- Em muốn refactor method nào?
- Vấn đề cụ thể hiện tại là gì?
- Nếu không refactor thì risk là gì?
- Nếu refactor thì những flow nào có thể bị ảnh hưởng?
- Mình có test hoặc regression checklist để cover chưa?
Sau khi có đủ thông tin, mình sẽ quyết định nên làm ngay hay để sau.
Điểm hay của cách nói này là bạn không phủ nhận ý kiến của bạn ấy, nhưng bạn kéo bạn ấy về hướng phân tích chuyên nghiệp.
4. Framework quyết định: khi nào nên refactor?
REFRACTOR DECISION FRAMEWORK
┌─────────────────────────────┐
│ Có đề xuất refactor không? │
└──────────────┬──────────────┘
│
v
┌──────────────────────────────────────┐
│ 1. Refactor này có liên quan trực tiếp│
│ đến feature đang làm không? │
└──────────────┬───────────────────────┘
│
┌────────┴────────┐
│ │
Có Không
│ │
v v
┌───────────────────────┐ ┌────────────────────────┐
│ Đi tiếp câu hỏi 2 │ │ Không làm trong scope │
│ │ │ hiện tại, ghi tech debt │
└───────────┬───────────┘ └────────────────────────┘
│
v
┌───────────────────────────────────────┐
│ 2. Nếu không refactor thì feature có │
│ dễ sai, khó maintain, hoặc gây bug? │
└───────────┬───────────────────────────┘
│
┌────────┴────────┐
│ │
Có Không
│ │
v v
┌──────────────────────┐ ┌────────────────────────┐
│ Đi tiếp câu hỏi 3 │ │ Ưu tiên delivery trước │
└──────────┬───────────┘ │ Refactor để sau │
│ └────────────────────────┘
v
┌──────────────────────────────────────┐
│ 3. Scope refactor có nhỏ và kiểm soát │
│ được không? │
└──────────┬───────────────────────────┘
│
┌───────┴────────┐
│ │
Có Không
│ │
v v
┌──────────────────────┐ ┌────────────────────────┐
│ Đi tiếp câu hỏi 4 │ │ Tách ticket riêng │
└──────────┬───────────┘ │ Không làm chung feature │
│ └────────────────────────┘
v
┌──────────────────────────────────────┐
│ 4. Có unit test/regression checklist │
│ đủ để bảo vệ flow cũ không? │
└──────────┬───────────────────────────┘
│
┌───────┴────────┐
│ │
Có Không
│ │
v v
┌──────────────────────┐ ┌────────────────────────┐
│ Có thể refactor │ │ Không refactor ngay │
│ nhưng giới hạn scope │ │ Bổ sung test trước │
└──────────────────────┘ └────────────────────────┘
5. Khi nào nên refactor ngay?
Nên refactor khi có các dấu hiệu này:
NÊN REFACTOR NGAY
├─ Logic cũ đang gây bug thật
├─ Feature mới bắt buộc phải thay đổi logic đó
├─ Không refactor thì code mới phải workaround nhiều
├─ Scope refactor nhỏ, rõ ràng
├─ Biết chính xác những flow bị ảnh hưởng
├─ Có unit test hoặc regression checklist
├─ Có đủ thời gian review và test
└─ Refactor giúp giảm risk delivery, không phải tăng risk
Ví dụ bạn có thể nói:
Nếu method hiện tại đang làm cho feature mới dễ sai hoặc phải duplicate logic nhiều nơi,
thì mình có thể refactor. Nhưng mình sẽ giới hạn phạm vi refactor trong đúng method liên quan,
không mở rộng sang các phần khác.
6. Khi nào không nên refactor?
Không nên refactor nếu lý do chỉ là:
KHÔNG NÊN REFACTOR LÚC NÀY
├─ "Code này nhìn chưa đẹp"
├─ "Em nghĩ có thể viết tốt hơn"
├─ Không có bug cụ thể
├─ Không ảnh hưởng trực tiếp feature hiện tại
├─ Không biết flow nào sẽ bị ảnh hưởng
├─ Không có test cover
├─ Refactor làm tăng scope của ticket
├─ Deadline đang gấp
├─ Khách hàng đang ưu tiên delivery
└─ Người đề xuất chưa phân tích đủ impact
Bạn có thể phản hồi:
Ý tưởng refactor này hợp lý về mặt technical debt, nhưng hiện tại anh chưa thấy nó là blocker
cho feature đang làm. Nếu mình đưa vào scope hiện tại thì risk regression sẽ tăng.
Anh đề xuất mình ghi nhận lại thành follow-up ticket, sau khi feature ổn định thì mình xử lý riêng.
7. Cách “loại trừ” phương án refactor mà vẫn giữ động lực cho member
Bạn nên tránh nói:
Không cần refactor.
Cái này không quan trọng.
Em phân tích chưa đúng.
Đừng làm phức tạp vấn đề.
Nên nói:
Anh nghĩ đề xuất này có giá trị, nhưng chưa phù hợp để đưa vào scope hiện tại.
Lý do là:
- Refactor này chưa phải blocker trực tiếp cho feature.
- Mình chưa có đủ regression coverage.
- Nếu thay đổi logic cũ lúc này, risk ảnh hưởng flow hiện tại khá cao.
- Khách hàng đang ưu tiên delivery nhanh và ổn định.
Vì vậy, hướng xử lý tốt hơn là:
- Không refactor trong ticket hiện tại.
- Ghi nhận thành technical debt.
- Tạo follow-up ticket nếu cần.
- Chỉ refactor khi có đủ impact analysis và test coverage.
8. Checklist yêu cầu member chuẩn bị
Trước khi accept refactor, bạn có thể yêu cầu member trả lời checklist này:
REFACTOR IMPACT CHECKLIST
1. Method/class/component nào cần refactor?
2. Lý do refactor là gì?
- Bug?
- Maintainability?
- Performance?
- Duplicate logic?
- Feature mới bị block?
3. Nếu không refactor thì hậu quả là gì?
4. Nếu refactor thì flow nào có thể bị ảnh hưởng?
5. Có bao nhiêu màn hình/component đang dùng logic này?
6. Có unit test hiện tại không?
7. Cần bổ sung test nào?
8. Có regression checklist không?
9. Estimate refactor là bao lâu?
10. Refactor này có làm trễ feature chính không?
Nếu bạn ấy chưa trả lời được các câu này, bạn có cơ sở chuyên nghiệp để nói:
Hiện tại mình chưa đủ thông tin để đưa refactor này vào scope chính.
9. Câu trả lời mẫu trong meeting/chat team
Bạn có thể dùng nguyên đoạn này:
Anh hiểu ý em. Phần code cũ đúng là có thể có điểm cần cải thiện,
và anh đánh giá cao việc em chủ động nhìn vào chất lượng code.
Tuy nhiên, ở giai đoạn hiện tại, khách hàng đang cần delivery nhanh nhưng feature vẫn phải ổn định.
Vì vậy, mình không nên refactor chỉ vì code có thể viết đẹp hơn. Mình chỉ nên refactor trong ticket
hiện tại nếu nó trực tiếp ảnh hưởng đến feature, gây bug, hoặc nếu không refactor thì implementation
mới sẽ rủi ro hơn.
Với đề xuất này, anh muốn mình làm rõ thêm impact trước:
- Method nào cần refactor?
- Flow nào đang dùng method đó?
- Nếu thay đổi thì regression risk là gì?
- Có test hoặc checklist nào để cover không?
Nếu impact nhỏ và có thể kiểm soát, mình có thể refactor trong scope nhỏ. Còn nếu impact lớn
hoặc chưa đủ test, anh nghĩ mình nên ghi nhận thành technical debt/follow-up ticket để xử lý sau,
tránh ảnh hưởng delivery hiện tại.
10. Tư duy lead nên giữ
Good Lead Decision
= Không reject idea quá nhanh
+ Không accept refactor theo cảm tính
+ Bắt team phân tích impact
+ Bảo vệ delivery
+ Bảo vệ quality
+ Giữ động lực member
Câu chốt: Refactor là tốt, nhưng refactor đúng thời điểm, đúng scope, có test và có impact analysis thì mới thực sự tạo giá trị. Còn refactor không kiểm soát có thể biến một improvement nhỏ thành regression lớn.