Cách Đánh Giá Chất Lượng Code Của Một Vendor Outsourcing Trước Khi Ký Hợp Đồng

Phần lớn quy trình đánh giá vendor cho công việc kỹ thuật outsource chỉ dừng lại ở case study và cuộc gọi tham khảo (reference call). Cả hai đều hữu ích, nhưng cả hai đều đã được chọn lọc kỹ — vendor tự chọn case study, còn người tham khảo là người đã đồng ý nói những điều tốt đẹp. Nếu muốn một tín hiệu thực sự về việc một đội ngũ có viết và duy trì được code production hay không, bạn phải yêu cầu những tài liệu khó dàn dựng hơn: pull request gần đây, bản ghi quyết định kiến trúc (ADR), và báo cáo test coverage thực tế, chứ không phải slide tóm tắt về chúng.

Yêu cầu pull request mẫu, không phải portfolio

Một sản phẩm trong portfolio mang tính hồi cố và đã được đánh bóng. Một pull request từ 90 ngày gần nhất, lý tưởng là từ một dự án khách hàng đang hoạt động với các chi tiết nhận dạng đã được ẩn đi, cho bạn biết đội ngũ thực sự làm việc hàng ngày ra sao. Khi chúng tôi ở phía bên kia của cuộc trò chuyện này — tức là đang được đánh giá với vai trò vendor — yêu cầu chúng tôi tôn trọng nhất là: "cho tôi xem ba PR, một cái nhận nhiều comment review, một cái được duyệt nhanh, và một cái bị revert hoặc phải hotfix."

Những gì cần chú ý:

• Kích thước PR. Diff liên tục trên 500 dòng cho thấy tần suất tích hợp thấp và rủi ro bỏ qua review cao hơn. Hầu hết các đội khỏe mạnh giữ PR trung vị dưới 200-300 dòng.
• Chất lượng comment review. Những comment kiểu "LGTM" ở mọi PR là một dấu hiệu đáng lo ngại. Những comment đặt câu hỏi như "nếu call này timeout thì sao" hay "cái này lặp logic ở X, có thể tách ra không" cho thấy reviewer thực sự đọc diff.
• PR bị revert. Việc revert được xử lý ra sao — âm thầm, hay có ghi chú bằng văn bản về cái gì đã sai và test nào đáng lẽ đã bắt được lỗi đó? Cách thứ hai là dấu hiệu của một đội ngũ học được từ sự cố thay vì chỉ lướt qua nó.

Bản ghi quyết định kiến trúc tiết lộ cách một đội ngũ tư duy, không chỉ những gì họ xây dựng

Code cho bạn thấy kết quả đầu ra. ADR cho bạn thấy quá trình lập luận — và chất lượng lập luận là chỉ báo tốt hơn nhiều cho việc đội ngũ sẽ xử lý những quyết định bạn chưa từng nghĩ tới ra sao. Một ADR hữu ích nêu rõ quyết định, bối cảnh buộc phải đưa ra quyết định đó, ít nhất một phương án thay thế đã được cân nhắc nghiêm túc, và đánh đổi đã chấp nhận. Nếu một vendor không thể đưa ra bất kỳ ADR nào, điều đó không nhất thiết loại họ khỏi một dự án nhỏ, nhưng nó có nghĩa là các quyết định kiến trúc chỉ đang tồn tại trong đầu người ta hoặc trên Slack, thứ không sống sót qua việc thay đổi nhân sự.

Khi xem xét ADR của một vendor, ba câu hỏi phân biệt đội mạnh với đội yếu:

1. Bản ghi có cho thấy một phương án thay thế thực sự đã bị từ chối, kèm lý do nêu rõ — hay nó chỉ biện minh cho cái đã được quyết định từ trước?
2. Có một điều kiện kích hoạt xem xét lại (revisit trigger) không — một điều kiện mà đội ngũ nói "chúng ta nên xem xét lại cái này nếu X xảy ra"? Những đội viết ra điều này thường thực sự bắt được đúng lúc X xảy ra.
3. ADR có được tham chiếu lại sau này, trong comment code hay các ADR tiếp theo không? Nếu chúng chỉ được viết một lần rồi không bao giờ đụng tới nữa, đó là hình thức, không phải thực hành thật.

Báo cáo test coverage cần ngữ cảnh, không chỉ một con số phần trăm

Một vendor đưa ra "92% coverage" mà không có giải thích thêm thì gần như không nói lên điều gì — coverage theo dòng trên các getter và setter được tính giống hệt như coverage trên logic đối soát thanh toán. Thay vào đó, hãy yêu cầu:

• Coverage được phân tách theo module, để bạn thấy được liệu đường đi quan trọng (auth, thanh toán, tính toàn vẹn dữ liệu) có thực sự được test kỹ hay con số coverage chỉ đang được đẩy lên nhờ code tầm thường.
• Coverage có bao gồm integration test hay chỉ unit test. Một codebase có 95% unit coverage và không có integration test vẫn có thể ship một API contract bị hỏng.
• Kết quả mutation testing, nếu có. Ít vendor chạy mutation testing, nhưng một vendor làm điều đó đang phát tín hiệu về mức độ nghiêm ngặt đáng ghi nhận — nó đo xem test có thực sự bắt được bug hay không, chứ không chỉ đo xem dòng code có được thực thi hay không.

Một dấu hiệu đáng lo ngại cần gọi thẳng tên

Hãy cẩn trọng với những con số coverage xuất hiện đột ngột ngay trước buổi trao đổi bán hàng. Hỏi xem việc báo cáo được thiết lập từ khi nào và liệu nó có được theo dõi liên tục trong CI hay chỉ được tạo ra theo yêu cầu. Một dashboard đã chạy cả năm và cho thấy đường xu hướng coverage đáng tin cậy hơn nhiều so với một ảnh chụp màn hình tại một thời điểm.

Chạy một bài kiểm tra kỹ thuật trực tiếp thay đổi cả cuộc trò chuyện

Tín hiệu đáng tin cậy nhất chúng tôi từng thấy khách hàng sử dụng — và cũng là thứ chúng tôi hoan nghênh nhất khi bị đánh giá — là một bài tập có trả phí, giới hạn thời gian: một ticket nhỏ thật (hoặc gần giống thật), được review theo đúng cách vendor review code production, với khách hàng ngồi tham dự buổi review. Nó tốn vài nghìn đô và vài ngày, nhưng cho bạn biết nhiều hơn ba vòng gọi tham khảo. Bạn thấy được các comment review thực tế trao đổi theo thời gian thực, thói quen viết test thực sự, và cách đội ngũ phản ứng trước sự phản biện về chính lựa chọn thiết kế của họ.

Không có kiểm tra nào trong số này quá lạ lùng. Chúng đều là mức độ nghiêm ngặt mà một quản lý kỹ thuật giỏi áp dụng khi phỏng vấn một ứng viên senior, chỉ là áp dụng cho quan hệ với vendor thay vì một cá nhân. Những vendor đáng hợp tác sẽ không né tránh yêu cầu này — họ thường đã chuẩn bị sẵn các tài liệu trước khi bạn kịp hỏi.