Đặt câu hỏi hữu ích trong lần duyệt mã backend đầu tiên
Đặt câu hỏi chính xác về danh tính, cập nhật một phần và tác động bên ngoài khi còn đang học kho mã backend.
Bạn có thể đặt câu hỏi hữu ích trong lần duyệt mã backend trước khi biết mọi thư viện của kho mã. Bắt đầu từ hành vi mà bản sửa cần bảo đảm, rồi xác định giả định nào mình chưa kiểm chứng được. Tôi coi trọng câu hỏi cụ thể kèm tình huống lỗi hơn lời nhận xét đầy tự tin nhưng chỉ lặp một mẫu từ dự án không liên quan.
Hình dung bạn đang duyệt điểm cuối cập nhật tài khoản giả định. Bản sửa cho phép đổi tên hiển thị và địa chỉ email. Bạn hiểu biểu mẫu nhưng chưa quen quy ước về danh tính và giao dịch của dịch vụ. Chừng đó đủ để bắt đầu duyệt cẩn thận mà không giả vờ đã hoàn thành một cuộc kiểm tra bảo mật.
Đọc thay đổi từ phía bên gọi
Tìm đầu vào được chấp nhận, danh tính bên gọi và bản ghi được sửa. Điểm cuối lấy tài khoản từ phiên đã xác thực hay nhận mã tài khoản trong yêu cầu? Nếu nhận mã, quyền sửa tài khoản đó được kiểm tra ở đâu?
Câu hỏi hữu ích có thể là: “Điều gì ngăn yêu cầu này sửa tài khoản khác nếu đổi mã định danh? Tôi đã thấy kiểm tra đầu vào nhưng chưa tìm được kiểm tra quyền trên đối tượng.” Câu hỏi nêu phần đã xem và bằng chứng còn thiếu. Nó không kết luận tác giả tạo lỗ hổng trước khi xem mã xung quanh.
Hướng dẫn duyệt mã của Google đề cập thiết kế, chức năng, độ phức tạp và kiểm thử. Các nhóm đó giúp tổ chức việc đọc bản sửa chưa quen. Bạn có thể duyệt hợp đồng quan sát được, đồng thời nhờ người hiểu miền xác nhận quy ước riêng của kho mã.
Tách câu hỏi theo quyết định bị ảnh hưởng
Với ví dụ tài khoản, các câu hỏi hữu ích có thể là:
| Câu hỏi | Vì sao liên quan đến thay đổi này? |
|---|---|
| Danh tính nào quyết định tài khoản được sửa? | Kiểm tra đầu vào không tự chứng minh quyền |
| Đổi email có cần xác minh không? | Sản phẩm có thể phân biệt địa chỉ yêu cầu với địa chỉ đã tin cậy |
| Những trường nào thay đổi cùng nhau? | Cập nhật một phần có thể để lại trạng thái ngoài ý muốn |
| Sau khi mất phản hồi thì sao? | Thử lại có thể lặp thông báo hoặc tác động phụ khác |
| Máy khách nào đang phụ thuộc phản hồi? | Thay đổi có vẻ nội bộ có thể đổi hợp đồng dùng chung |
Các câu hỏi không phải danh sách phổ quát có thể chứng nhận một điểm cuối. Chúng gắn với trường và hành vi trong bản sửa này. Luồng đổi ảnh đại diện hoặc đặt lại mật khẩu cần chú ý những điểm khác.
Sơ đồ tách tác động bên ngoài khỏi lần ghi cơ sở dữ liệu. Giao dịch bao quanh các trường tài khoản không tự khiến email xác minh có tính nguyên tử cùng các thay đổi ấy. Người duyệt cần hiểu ứng dụng xử lý khoảng cách đó thế nào.
Yêu cầu ví dụ hành vi
Nếu khó lần theo cách thực hiện, hãy yêu cầu trường hợp cụ thể. “Điều gì phải xảy ra khi email mới đã được dùng?” cho tác giả kết quả cần giải thích. Sau đó tìm kiểm tra hợp lệ, ràng buộc cơ sở dữ liệu và phép thử thiết lập kết quả ấy.
Giả sử phép thử chỉ kiểm tra điểm cuối có trả phản hồi. Bằng chứng đó yếu hơn việc kiểm tra trạng thái mong đợi, giá trị đã lưu và việc không xảy ra tác động phụ bị cấm. Giải thích bằng chứng thiếu thay vì yêu cầu “thêm test” mà không nêu mục đích.
Bảng trường hợp nhỏ giúp hai người thống nhất hợp đồng trước khi tranh luận chi tiết thực hiện. Đưa vào một lần cập nhật bình thường, một giá trị không hợp lệ và một xung đột liên quan. Nếu trường hợp phụ thuộc quy tắc sản phẩm chưa nêu, xác định người quyết định thay vì tự sáng tác quy tắc trong bình luận duyệt mã.
Viết bình luận dễ trả lời
Hướng dẫn viết bình luận của Google khuyên giải thích lý do và tôn trọng lập trình viên. Bình luận nên giúp tác giả hiểu hậu quả bạn lo ngại và điều gì sẽ giải quyết mối lo.
So sánh “Sai rồi, dùng giao dịch đi” với “Tên hiển thị được lưu trước khi kiểm tra tính duy nhất của địa chỉ email kết thúc. Nếu lần ghi thứ hai thất bại, thay đổi đầu có nên còn không? Nếu thao tác cần nguyên tử, có thể kiểm tra trường hợp thất bại giữa chừng này không?” Bình luận thứ hai làm rõ yêu cầu và chừa khả năng có cơ chế sẵn mà bạn chưa thấy.
Phân biệt vấn đề về tính đúng đắn cần giải quyết trước khi duyệt với góp ý đặt tên hoặc tổ chức. Người chưa quen kho mã càng cần tránh biến sở thích riêng thành yêu cầu. Đồng thời, chưa chắc chắn không phải lý do bỏ qua rủi ro cụ thể.
Khép lại việc học từ lần duyệt
Sau khi tác giả trả lời, xem cơ chế được dẫn ra và cập nhật cách hiểu. Nếu quyền truy cập nằm trong lớp bọc dịch vụ chung, lần theo đúng đường của điểm cuối này và ghi điều lớp bọc bảo đảm. Nếu bản sửa thay đổi, đọc phần chênh lệch mới rồi chạy lại hoặc xem phép kiểm tra liên quan theo quy trình duyệt.
Giữ một bài học có thể dùng lại, như “kho mã này xác định chủ tài khoản tại ranh giới dịch vụ” hoặc “điểm cuối này chủ ý tách email yêu cầu khỏi email đã xác minh”. Tránh khái quát nó thành quy tắc cho mọi dự án.
Giới hạn của lần duyệt đầu là có thật: bạn có thể bỏ sót hành vi người bảo trì giàu kinh nghiệm sẽ nhận ra. Duyệt cùng họ có thể cải thiện kết quả và cho bạn mô hình cụ thể để dùng lại. Đóng góp của bạn là câu hỏi cẩn thận, bằng chứng đã xem và việc sẵn sàng sửa kết luận khi mã trả lời được.
Lần theo địa chỉ được yêu cầu đến lúc xác minh
Mở rộng ví dụ tài khoản bằng quy tắc sản phẩm được đề xuất: email yêu cầu chưa trở thành địa chỉ tin cậy cho đến khi xác minh thành công. Khi duyệt cần phân biệt địa chỉ hiện đã xác minh, địa chỉ đang chờ và mã thay đổi đang chờ. Ý nghĩa đó không bắt buộc tên cột cụ thể, nhưng cách thực hiện phải giữ được sự phân biệt.
Giả sử tài khoản đang tin cậy E0. Người dùng yêu cầu E1 dưới thay đổi C1, rồi yêu cầu E2 dưới C2 trước khi dùng liên kết xác minh đầu. Trong bài tập này, quy tắc đã thống nhất là C2 thay thế C1. Liên kết thuộc C1 không được xác minh E2 chỉ vì E2 hiện là địa chỉ đang chờ.
Bình luận chính xác là: “Hàm xác minh đọc email đang chờ hiện tại sau khi tìm thấy mã này. Kiểm tra nào buộc mã với đúng thay đổi đã yêu cầu? Có thể thử C1, rồi C2, rồi liên kết C1 cũ và xác nhận E0 vẫn là địa chỉ đã xác minh không?” Bình luận nêu thứ tự và kết quả mong đợi mà không ép định dạng mã xác minh.
Đây là bài tập chính sách sản phẩm, không phải thiết kế xác minh email đầy đủ. Tính khó đoán, thời hạn, việc chỉ dùng một lần, gắn với tài khoản và luồng xác thực xung quanh cần được duyệt bảo mật phù hợp. Một câu hỏi tốt về liên kết cũ chưa bao quát tất cả nghĩa vụ đó.
Theo bằng chứng qua đường gọi đã thay đổi
Tác giả có thể trả lời rằng lớp bọc dùng chung kiểm tra quyền, hoặc hàm hỗ trợ giao dịch sẵn có bảo đảm hai lần ghi tài khoản là nguyên tử. Lần theo điểm cuối thực tế qua đúng lớp bọc hoặc hàm đó. Mã tương tự ở nơi khác và phép thử đơn vị thành công cho hàm hỗ trợ chưa chứng minh tuyến đang sửa gọi nó với đầu vào đúng.
Giữ bản đồ bằng chứng nhỏ. Với đầu vào bình thường, xác định tài khoản lưu và phản hồi mong đợi. Với mã tài khoản khác, tìm đường từ chối và kiểm tra không tài khoản hay thông báo nào thay đổi. Với địa chỉ xung đột, xác định cả hai trường giữ nguyên hay sản phẩm chủ ý nhận một phần yêu cầu. Với chuỗi C1/C2, tìm phép so sánh thay đổi đang chờ tại lúc xác minh.
Bản đồ này hữu ích hơn đếm số tệp kiểm thử. Phép thử có thể chạy qua dòng thay đổi mà vẫn không xác nhận hành vi đang bàn. Ngược lại, phép thử tích hợp sẵn có thể đã chứng minh trường hợp đó; yêu cầu thêm phép thử gần như giống hệt không mang lại nhiều giá trị. Đọc xem bằng chứng thiết lập điều gì trước khi yêu cầu bộ dữ liệu mới.
Sau khi sửa, kiểm tra lại đường gọi đã đổi. Bản sửa có thể chuyển kiểm tra quyền lên sớm nhưng vô tình bỏ qua nó ở điểm vào thứ hai. Đọc lại phạm vi bản sửa và các bên gọi là việc duyệt cụ thể; tuyên bố đã kiểm tra lại toàn bộ dịch vụ là phạm vi lớn hơn nhiều.
Nêu điều gì ngăn duyệt và điều gì có thể làm sau
Tiêu chuẩn duyệt mã của Google ưu tiên thay đổi cải thiện chất lượng mã tổng thể mà không đòi hỏi hoàn hảo. Tài liệu cũng phân biệt bằng chứng kỹ thuật với sở thích, và cho phép bình luận hướng dẫn được ghi rõ là không bắt buộc. Điều đó giúp người duyệt mới vừa cẩn thận vừa hữu ích.
Với bản sửa tài khoản, đường chưa giải quyết có thể cập nhật nhầm tài khoản là vấn đề về tính đúng đắn cần xử lý. Câu hỏi lớp bọc quen dùng được gọi ở đâu là yêu cầu bằng chứng; sau khi được trả lời và kiểm tra, có thể không cần đổi mã. Góp ý đổi tên biến cục bộ có thể theo quy tắc phong cách của kho mã mà không cản thay đổi hành vi đã đúng.
Ghi kết luận cùng phạm vi công việc: đã xem trường hợp nào, lời giải thích nào giải quyết câu hỏi và còn cần chuyên gia duyệt ranh giới chưa quen hay không. Mục tiêu là quyết định dễ hiểu về bản sửa này. Bạn có thể học từ trao đổi mà không biến mọi quan sát hữu ích thành một yêu cầu nữa cho tác giả.