Career & Non-TechĐây là tình huống rất hay gặp ở công ty product lâu năm và công ty outsourcing nhận dự án bàn giao. Người hỏi muốn thấy phương pháp, không phải sự tự tin.
Thứ tự tiếp cận:
1. Chạy được đã, hiểu sau. Dựng môi trường chạy local trước tiên. Vừa dựng vừa ghi lại các bước — đó chính là trang tài liệu đầu tiên của hệ thống.
2. Đi từ ngoài vào. Bắt đầu từ điểm vào: route/endpoint, màn hình chính, cron job. Đọc theo một luồng nghiệp vụ hoàn chỉnh (ví dụ luồng đặt hàng) thay vì đọc theo thư mục.
3. Dùng lịch sử Git. git log theo file cho biết vùng nào thay đổi nhiều (thường là vùng rủi ro), commit message và pull request cũ thường là tài liệu duy nhất còn lại.
4. Đọc schema và dữ liệu thật. Cấu trúc bảng và ràng buộc cho biết mô hình nghiệp vụ chính xác hơn code.
5. Dựng lưới an toàn trước khi sửa. Viết test đặc tả (characterization test) chốt lại hành vi hiện tại — kể cả hành vi trông như lỗi — rồi mới refactor. Thêm log và cảnh báo ở phần bạn sắp đụng vào.
6. Sửa từng phần nhỏ theo nhu cầu thật. Refactor vùng nào bạn đang phải sửa bug, không viết lại toàn bộ.
Ví dụ mẫu: "Em nhận một hệ thống PHP không có test. Tuần đầu em chỉ dựng môi trường và viết lại tài liệu cài đặt. Sau đó em vẽ sơ đồ luồng thanh toán bằng cách đọc từ controller xuống. Trước khi sửa bug tính thuế, em viết 12 test khoá lại hành vi hiện tại. Nhờ vậy khi refactor phần tính giá, em phát hiện được hai chỗ mình vô tình làm đổi kết quả."
Lỗi hay mắc:
- Đề xuất viết lại từ đầu ngay trong câu trả lời — đây là dấu hiệu thiếu kinh nghiệm, gần như luôn bị hỏi vặn về chi phí và rủi ro.
- Đọc code dàn trải theo thư mục, không theo luồng, dẫn tới hiểu rời rạc.
- Sửa vào phần lõi khi chưa có test nào bảo vệ.
Điểm cộng: nhắc tới việc hỏi người dùng nghiệp vụ khi code không nói được ý định, và việc tích luỹ tài liệu dần theo từng lần sửa thay vì làm một đợt viết tài liệu lớn.