Cách tôi đo công việc kỹ thuật của mình
Cách tôi đo công việc kỹ thuật của mình
Tốc độ không phải là chỉ số. Độ bền mới là chỉ số.

On this page
Tôi không tin vào "tốc độ" như một chỉ số đo lường công việc kỹ thuật. Tôi tin vào độ bền — tức là sản phẩm tôi viết ra có còn đứng vững sau ba tháng, sáu tháng, một năm hay không.
Một feature ship nhanh nhưng vỡ lúc người khác sờ vào, đối với tôi là feature thất bại. Một feature ship chậm một tuần nhưng ba tháng sau vẫn không sinh bug, không cần ai phải hiểu lại từ đầu — đó là feature thành công.
Cách tôi đo công việc của bản thân, nói thẳng ra, là đếm số lần phải quay lại sửa. Một module tôi viết xong rồi không phải đụng tới trong nửa năm là một module tốt. Một module tôi phải patch ba lần trong một tháng là một module tôi đã viết ẩu — bất kể nó ship nhanh tới đâu.
Ba câu hỏi tôi tự hỏi trước khi merge#
Trước khi gửi một pull request, tôi tự hỏi ba câu:
- Nếu sáu tháng nữa tôi quên hết, đọc lại code này tôi có hiểu được không?
- Nếu một người mới vào team đọc code này, họ có biết tại sao nó ở đây, hay họ phải đi hỏi tôi?
- Nếu có bug, tôi có biết bắt đầu sửa từ đâu không?
Nếu câu trả lời cho bất kỳ câu nào là không chắc, tôi không merge.
Tại sao tôi không đo bằng số lượng commit#
Số lượng commit, số dòng code, số PR — tất cả những thứ đó là proxy metric. Chúng dễ đo, dễ báo cáo, nhưng không phản ánh giá trị thực. Một dòng code đúng có thể đáng giá bằng năm trăm dòng phải viết lại.
Cái tôi muốn đo là: hệ thống có ngày càng dễ thay đổi hơn không. Mỗi PR mới, codebase trở nên dễ bảo trì hơn — hay khó hơn? Đây là câu hỏi quan trọng nhất, và cũng là câu hỏi khó đo nhất.
Một cách thực hành đơn giản#
Mỗi lần tôi đụng vào một module mình từng viết, tôi tự hỏi: nếu phải viết lại từ đầu, tôi có viết khác đi không? Nếu câu trả lời là không — nghĩa là module đó vẫn đứng vững. Nếu câu trả lời là có, khác nhiều — nghĩa là tôi đã học được gì đó, và đến lúc refactor một chút.
Nhưng chỉ refactor cái tôi vừa đụng vào. Đừng refactor toàn bộ codebase chỉ vì có một insight mới. Cách làm đó tốn thời gian, tạo ra bug, và không ai cảm ơn bạn cả. Refactor cục bộ, theo từng PR — đó là cách codebase tự tiến hoá mà không vỡ.