Xem lại mã có ích nhất khi tập trung vào những gì máy không kiểm tra được: logic đã đúng chưa, trường hợp biên có được xử lý không, có lỗ hổng bảo mật không, người sau đọc có hiểu không. Góp ý nói về mã chứ không nói về người, phân biệt rõ điều bắt buộc sửa với điều chỉ là gợi ý, và nên xem sớm, từng phần nhỏ.
Chào bạn, đây là Nhà Lập Trình. Trong nhiều đội, trước khi mã được đưa vào nhánh chính, một đồng nghiệp khác phải đọc và đồng ý. Việc này có thể là nơi cả đội học hỏi lẫn nhau, cũng có thể là nơi sinh ra bực bội và mất thời gian. Tập này kể cách làm cho nó thành cái thứ nhất.
Xem lại mã để làm gì?
Mục đích rõ nhất là bắt lỗi trước khi tới tay người dùng. Một cặp mắt thứ hai thấy những thứ người viết không thấy, vì người viết biết mình định làm gì và não tự lấp chỗ trống.
Nhưng lợi ích lớn hơn nhiều người không nhận ra là chia sẻ hiểu biết. Khi bạn xem mã của đồng nghiệp, bạn biết thêm về phần hệ thống họ đang làm. Khi họ nghỉ phép hay rời đội, luôn có ít nhất một người khác hiểu phần đó.
Xem lại mã cũng là nơi người mới học nhanh nhất. Đọc mã người giỏi, và được người giỏi góp ý cho mã của mình, dạy nhiều hơn mọi khoá học.
Và nó giữ cho mã của cả đội có cùng một phong cách, cùng một chuẩn mực. Không phải vì có luật, mà vì mọi người liên tục thấy mã của nhau.
Soi gì trước, để máy lo gì
Thời gian và sự tập trung của người xem có hạn, nên hãy dùng nó cho những thứ quan trọng. Thứ tự mình hay dùng: trước tiên, thay đổi này có làm đúng điều nó định làm không. Đọc mô tả, hiểu yêu cầu, rồi xem mã có giải quyết đúng yêu cầu đó không.
Tiếp theo là những gì có thể gây hại: trường hợp biên bị bỏ sót, dữ liệu nửa vời khi lỗi xảy ra, lỗ hổng bảo mật, truy vấn chậm với dữ liệu lớn, thay đổi phá vỡ chức năng khác.
Sau đó là khả năng đọc hiểu: tên có rõ không, có chỗ nào khó hiểu cần chú thích không, có thể viết đơn giản hơn không.
Còn những thứ như thụt đầu dòng, khoảng trắng, thứ tự khai báo, hãy để máy lo. Cài công cụ định dạng tự động và công cụ kiểm tra quy ước cho cả đội. Cãi nhau về dấu cách trong buổi xem lại mã là lãng phí thời gian và làm mọi người mệt mỏi.
Góp ý về mã, không về người
Cách viết góp ý quyết định đồng nghiệp nhận nó thế nào. Bạn viết tại sao bạn lại làm thế này, nghe như chất vấn. Bạn viết đoạn này có thể lỗi khi danh sách rỗng, mình nghĩ nên kiểm tra thêm, nghe như cùng làm việc.
Nói về mã, không nói về người. Không phải bạn quên xử lý lỗi, mà là chỗ này chưa xử lý lỗi. Khác biệt nhỏ về chữ, lớn về cảm giác.
Giải thích lý do. Đừng chỉ nói đổi cái này. Hãy nói vì sao: vì cách này dễ bị chèn lệnh vào truy vấn, vì cách kia chạy chậm khi bảng lớn. Người viết học được điều gì đó, và có thể phản biện nếu họ biết bối cảnh bạn không biết.
Và khen những gì tốt. Một dòng như chỗ tách hàm này rõ ràng quá, không tốn gì nhưng cho người viết biết họ đang đi đúng hướng. Buổi xem lại mã chỉ toàn chê thì ai cũng sợ gửi.
Phân biệt bắt buộc và gợi ý
Không phải góp ý nào cũng quan trọng như nhau. Một lỗ hổng bảo mật thì bắt buộc sửa. Một cái tên có thể hay hơn thì chỉ là gợi ý. Nếu không phân biệt, người viết sẽ phải sửa mọi thứ, hoặc tranh luận mọi thứ, và thay đổi bị kẹt nhiều ngày.
Nhiều đội có quy ước đánh dấu: góp ý nào bắt đầu bằng chữ nhỏ hoặc tuỳ bạn là gợi ý, người viết có thể bỏ qua. Góp ý không có đánh dấu là cần giải quyết trước khi đồng ý.
Khi có bất đồng mà trao đổi qua lại hai ba lần chưa xong, hãy nói chuyện trực tiếp. Mười phút nói chuyện giải quyết được những gì cả chục lượt bình luận không giải quyết được.
Và nhớ rằng mục tiêu là mã đủ tốt để đưa lên, không phải mã giống hệt cách bạn sẽ viết. Có nhiều cách đúng. Nếu cách của đồng nghiệp đúng và rõ ràng, hãy đồng ý dù bạn thích cách khác hơn.
Thay đổi nhỏ, xem sớm, và khi mình là người viết
Một thay đổi hai nghìn dòng gần như không thể xem kỹ. Người xem sẽ đọc lướt và đồng ý cho xong. Một thay đổi hai trăm dòng thì xem được kỹ. Nên người viết hãy chia thay đổi thành từng phần nhỏ, mỗi phần làm một việc.
Người xem hãy xem sớm. Thay đổi nằm chờ ba ngày thì người viết đã chuyển sang việc khác, quên bối cảnh, và phải nhớ lại khi nhận góp ý. Nhiều đội đặt quy ước xem trong vòng một ngày làm việc.
Khi mình là người viết, hãy tự xem lại trước khi gửi, viết mô tả rõ ràng thay đổi làm gì và vì sao, chỉ ra những chỗ mình không chắc để người xem chú ý.
Và khi nhận góp ý, nhớ rằng người ta góp ý cho mã, không phải cho con người bạn. Cảm ơn, sửa, hoặc giải thích nếu bạn có lý do. Người nhận góp ý tốt là người được đồng nghiệp muốn làm việc cùng nhất.
Câu hỏi thường gặp
Xem lại mã nên tập trung vào điều gì?
Tập trung vào việc thay đổi có làm đúng yêu cầu không, trường hợp biên, bảo mật, hiệu năng với dữ liệu lớn và khả năng đọc hiểu. Phần định dạng nên để công cụ tự động lo.
Làm sao góp ý mã mà không làm đồng nghiệp khó chịu?
Nói về mã chứ không về người, giải thích lý do, phân biệt rõ điều bắt buộc với gợi ý, và khen những chỗ làm tốt. Bất đồng kéo dài thì nói chuyện trực tiếp.
Một thay đổi bao nhiêu dòng thì dễ xem lại?
Không có con số cố định, nhưng thay đổi càng nhỏ và làm một việc duy nhất thì càng được xem kỹ. Thay đổi rất lớn thường bị đọc lướt và dễ lọt lỗi.
Người mới có nên xem lại mã của người có kinh nghiệm không?
Nên. Người mới học được rất nhiều khi đọc mã của người giỏi, và câu hỏi của người mới thường chỉ ra những chỗ khó hiểu mà người viết không nhận ra.
Nên làm gì khi không đồng ý với góp ý?
Giải thích lý do và bối cảnh của mình một cách bình tĩnh. Nếu vẫn chưa thống nhất sau vài lượt trao đổi, hãy nói chuyện trực tiếp hoặc nhờ người thứ ba cho ý kiến.
