Đánh Giá Chất Lượng Code Khi Bạn Không Phải Lập Trình Viên

Đội ngũ phát triển vừa bàn giao tính năng mới. Mọi thứ hoạt động. Nút bấm phản hồi, dữ liệu được lưu, trang tải đúng như mong đợi. Bạn ký duyệt.

Ba tháng sau, một tính năng tưởng chừng đơn giản mất gấp bốn lần thời gian dự kiến. Một lỗi ở chỗ này lại kéo hỏng thứ khác hoàn toàn không liên quan. Lead developer của công ty outsource giải thích rằng đây là "vấn đề kỹ thuật phức tạp" — và bạn không có cách nào kiểm chứng điều đó.

Đây là điểm mù điển hình của founder không có nền tảng kỹ thuật. Và nó tốn tiền thật.

"Phần mềm chạy được" không phải là tiêu chí chất lượng. Đó chỉ là ngưỡng tối thiểu. Một codebase có thể vận hành trơn tru bề ngoài trong khi bên trong đang tích tụ hàng năm vấn đề — logic trùng lặp, không có test, không có tài liệu, dependency không ai cập nhật, quy trình triển khai phụ thuộc hoàn toàn vào một người có thể nghỉ việc bất cứ lúc nào.

Bạn không cần đọc code để nhận ra những vấn đề này sắp xảy ra. Bạn chỉ cần biết phải nhìn vào đâu.

Những Tín Hiệu Gián Tiếp Thực Sự Quan Trọng

Chất lượng kỹ thuật để lại dấu vết trong cách một đội nhóm vận hành, không chỉ trong sản phẩm họ tạo ra. Hãy chú ý những điều sau:

Họ nói về việc triển khai như thế nào?

Những đội nhóm lành mạnh triển khai thường xuyên và không có áp lực. Nếu vendor của bạn chỉ deploy một lần mỗi tháng, coi mỗi lần release là một sự kiện rủi ro, hoặc chỉ deploy vào thứ Sáu khi "mọi người đều có mặt" — đó là dấu hiệu cảnh báo. Deploy thường xuyên, tự động hoá, không căng thẳng là biểu hiện của code có cấu trúc tốt và quy trình vững chắc bên dưới.

Hỏi: "Các bạn deploy bao lâu một lần? Quy trình đó trông như thế nào?"

Pull request có được review không, hay chỉ merge thẳng?

Code review là cách các đội nhóm phát hiện vấn đề trước khi nó trở thành nợ kỹ thuật. Hãy hỏi liệu developer có review code của nhau trước khi đưa lên production không. Nếu câu trả lời là "nhóm nhỏ nên mình cứ merge thôi," bạn đang nhìn vào một quy trình bỏ qua cổng kiểm soát chất lượng quan trọng nhất trong phát triển phần mềm.

Họ xử lý lỗi như thế nào?

Codebase nào cũng có lỗi. Điều quan trọng là hệ thống xung quanh lỗi đó. Vendor của bạn có theo dõi lỗi một cách có hệ thống không? Họ có tìm hiểu nguyên nhân gốc rễ, hay chỉ vá triệu chứng? Một đội nhóm liên tục gặp lại cùng một loại lỗi — vấn đề đăng nhập, lỗi thanh toán, dữ liệu không nhất quán — có thể đang vá triệu chứng vì code gốc quá mong manh để xử lý đúng cách.

Họ nói về codebase với bạn như thế nào?

Một đội nhóm tự tin và trung thực có thể giải thích các quyết định kiến trúc bằng ngôn ngữ bình thường. Họ sẽ nói những thứ như "chúng tôi chọn cách này vì nó giúp X dễ thay đổi hơn sau này" hoặc "phần này của hệ thống cũ hơn và chúng tôi định refactor." Câu trả lời mơ hồ, thuật ngữ kỹ thuật quá mức, hay phản ứng phòng thủ khi bạn đặt câu hỏi — đó là dấu hiệu của đội nhóm không hiểu rõ sản phẩm họ đang xây, hoặc không muốn bạn hiểu.

Những Câu Hỏi Cần Đặt Ra Với Vendor

Bạn không cần kiến thức kỹ thuật để hỏi những câu này. Bạn chỉ cần can đảm hỏi và kiên nhẫn lắng nghe câu trả lời.

"Điều gì xảy ra nếu lead developer của các bạn nghỉ việc?"

Câu trả lời trung thực là: không có gì nghiêm trọng, vì kiến thức nằm trong code và tài liệu, không phải trong đầu một người. Nếu câu trả lời mơ hồ, hoặc có khoảng dừng lúng túng, có thể bạn đang phụ thuộc vào một cá nhân cụ thể nhiều hơn bạn nghĩ.

"Các bạn tài liệu hoá các quyết định như thế nào?"

Những đội nhóm tốt lưu lại lý do tại sao họ xây dựng theo cách đó — architecture decision records, comment trong code, wiki nội bộ. Nếu vendor của bạn không thể chỉ ra tài liệu đó nằm ở đâu, mỗi ngày bạn đang tích luỹ thêm nợ vô hình.

"Cho tôi xem quy trình từ khi có spec đến khi tính năng lên production?"

Lắng nghe để nghe một quy trình rõ ràng, có thể lặp lại: khám phá, lên kế hoạch, thiết kế, phát triển, review, kiểm thử, staging, production. Những khoảng trống trong chuỗi này — đặc biệt là ở khâu kiểm thử và review — là nơi các vấn đề chất lượng len vào.

"Test coverage của các bạn như thế nào?"

Bạn không cần hiểu test coverage là gì về mặt kỹ thuật. Bạn chỉ cần biết họ có nó không và họ có quan tâm đến nó không. Một đội nhóm chưa bao giờ được hỏi câu này và không có câu trả lời sẵn sàng — họ chưa thực sự nghĩ đến chất lượng.

"Phần nào trong codebase này các bạn ít tự hào nhất?"

Mọi developer có kinh nghiệm đều có câu trả lời thành thật cho câu hỏi này. Một đội nhóm nói "mọi thứ đều ổn" thì hoặc là không tư duy phản biện về công việc của mình, hoặc là không thành thật với bạn.

Dấu Hiệu Cảnh Báo Trong Mối Quan Hệ

Vấn đề chất lượng code thường xuất hiện trong cách ứng xử của đội nhóm trước khi nó lộ ra trong phần mềm.

Mọi thứ đều khẩn cấp. Nếu vendor của bạn biến mọi yêu cầu thành việc gấp, họ có thể đang làm việc trong một codebase rối rắm đến mức những thứ đơn giản cũng thực sự mất nhiều thời gian — và họ bù đắp bằng cách vội vàng thay vì giải thích tại sao các task lại mất lâu.

Không bao giờ phản đối yêu cầu. Một đội phát triển tốt đặt câu hỏi làm rõ và đôi khi từ chối các yêu cầu tính năng không hợp lý hoặc mâu thuẫn với cách hệ thống được xây dựng. Đội nhóm gật đầu với tất cả mọi thứ có thể không hiểu đủ hệ thống để biết khi nào nên nói không — hoặc đang ưu tiên doanh thu ngắn hạn hơn chất lượng dài hạn.

Không đặt câu hỏi trước khi bắt đầu làm. Phát triển tốt bắt đầu bằng sự hiểu biết. Nếu vendor của bạn im lặng sau khi nhận brief và xuất hiện lại với một tính năng hoàn chỉnh, họ đã bỏ qua bước làm rõ giúp tránh công việc lệch hướng — và kiểu code cẩu thả được viết ra khi không ai dừng lại để suy nghĩ.

Chậm trễ luôn được đổ cho "độ phức tạp kỹ thuật." Một số thứ thực sự phức tạp. Nhưng "kỹ thuật phức tạp" như một lý do lặp đi lặp lại cho sự chậm trễ, mà không có chi tiết cụ thể, đáng được đặt vấn đề. Hãy yêu cầu họ giải thích điều gì làm nó phức tạp. Nếu họ không thể nói rõ ràng, sự phức tạp có thể không phải là vấn đề thật sự.

So Sánh Chi Phí Để Thấy Rõ Vấn Đề

Một cuộc kiểm toán kỹ thuật đúng nghĩa — thuê một senior developer độc lập để review codebase và viết báo cáo — thường có chi phí từ 25 đến 120 triệu đồng tuỳ theo quy mô và mức phí của người review. Công việc này mất vài ngày đến một tuần.

Chi phí của việc tiếp nhận một codebase kém chất lượng:

• Viết lại toàn bộ một ứng dụng cỡ vừa: 1,2 tỷ đến 5 tỷ đồng trở lên
• Trượt tiến độ do nợ kỹ thuật tích luỹ: nhiều tháng
• Chi phí tuyển dụng khi các kỹ sư không muốn làm việc với hệ thống đó: có thật
• Cơ hội kinh doanh bị bỏ lỡ khi hệ thống quá mong manh để mở rộng: khó đo lường

Kiểm toán kỹ thuật là khoản bảo hiểm rẻ. Nếu bạn đã hợp tác được ba tháng và có gì đó không ổn, đáng để làm trước khi bạn đã đi được mười hai tháng và quá sâu để thay đổi hướng.

Quan trọng hơn: nếu vendor của bạn phản đối một cuộc kiểm toán độc lập, đó đã là câu trả lời của bạn rồi.

Những Gì Bạn Thực Sự Kiểm Soát Được

Bạn không thể đọc code. Nhưng bạn có thể đặt câu hỏi thông minh, quan sát cách đội nhóm vận hành, yêu cầu một quy trình minh bạch với bạn, và biết khi nào cần đưa vào một góc nhìn độc lập.

Những founder không có nền tảng kỹ thuật nhưng vẫn có được phần mềm tốt không phải là người học lập trình. Họ là người học cách phân biệt giữa một đội nhóm tự tin vì họ đang làm việc tốt và một đội nhóm tự tin vì bạn không biết đủ để đặt câu hỏi.

Sự phân biệt đó có giá trị hơn bất kỳ kỹ năng kỹ thuật nào.