Đối phó với một nhà phát triển liên tục bỏ qua các trường hợp cạnh trong công việc của mình

Tôi có một vấn đề thú vị, khá phổ biến tôi đoán, với một trong những nhà phát triển trong nhóm của tôi. Anh chàng này là một nhà phát triển tuyệt vời, làm việc nhanh và năng suất, sản xuất mã chất lượng khá tốt và tất cả. Kỹ sư giỏi. Nhưng có một vấn đề với anh ta - rất thường xuyên anh ta không giải quyết các trường hợp cạnh trong mã của mình.

Chúng tôi đã nói chuyện với anh ấy về điều đó nhiều lần và anh ấy đang cố gắng nhưng tôi đoán anh ấy không nghĩ theo cách này. Vì vậy, điều cuối cùng xảy ra là QA sẽ tìm thấy nhiều vấn đề với mã của anh ta và đưa nó trở lại để phát triển hết lần này đến lần khác, cuối cùng dẫn đến thời hạn bị bỏ lỡ và mọi người trong nhóm không hài lòng.

Tôi không biết phải làm gì với anh ta và làm thế nào để giúp anh ta khắc phục vấn đề này. Có lẽ ai đó có nhiều kinh nghiệm có thể khuyên?

Yêu cầu anh ta viết các bài kiểm tra đơn vị tự động cho mã của mình. Viết bài kiểm tra đơn vị buộc người ta phải suy nghĩ thông qua các trường hợp cạnh.

Một số chi tiết:

1. Để đảm bảo anh ta không cảm thấy độc thân, điều này nên được đặt ra cho toàn bộ đội của bạn. Yêu cầu mọi người viết bài kiểm tra đơn vị tự động cho mã mới hoặc mã họ sửa đổi.
2. Yêu cầu tên thử nghiệm đơn vị phải được mô tả như trường hợp chúng đang thử nghiệm.
3. Bao gồm các bài kiểm tra đơn vị tự động trong đánh giá mã ở mức cao. Yêu cầu các nhà phê bình tìm kiếm các trường hợp thử nghiệm bị bỏ lỡ (ví dụ như các trường hợp cạnh mà anh ta thường xuyên bỏ lỡ). Sau một số lượng phản hồi từ nhóm của anh ấy về các trường hợp bị bỏ sót, anh ấy có thể sẽ học cách xem xét những điều đó trước khi xem xét.
4. Thực thi quy tắc này cho toàn bộ nhóm: Nếu QA tìm thấy lỗi, nhà phát triển chịu trách nhiệm nợ kiểm tra tự động xác nhận lỗi và sau đó chứng minh rằng họ đã sửa nó. (trước khi họ làm bất kỳ công việc nào khác)

Đưa cho anh ấy một danh sách kiểm tra, vd

• đầu vào null
• đầu vào ở cuối cực lớn của phạm vi
• đầu vào ở cực nhỏ của phạm vi
• kết hợp
• đầu vào vi phạm các bất biến giả định (ví dụ: nếu x = y)

Những người QA có thể giúp đưa ra danh sách kiểm tra

Đưa danh sách kiểm tra cho tất cả các nhà phát triển, không chỉ cái này.

Kỹ sư giỏi.

Đuợc.

Nhưng có một vấn đề với anh ta - rất thường xuyên anh ta không giải quyết các trường hợp cạnh trong mã của mình.

Đó là một kỹ sư tốt chất lượng không chia sẻ.

Theo dõi các trường hợp cạnh là một đặc điểm có hoặc không có ở người. Nó không có gì để làm với một kỹ sư hoặc lập trình viên. Sự phát triển của đặc tính này bị ảnh hưởng bởi nền tảng văn hóa, môi trường sống, sự kiện thời thơ ấu và trải nghiệm cuộc sống. Sau đó, thái độ được áp dụng đơn giản cho bất kỳ công việc mà một cá nhân đang làm.

Những gì bạn cần là tìm hiểu xem anh chàng của bạn thuộc loại nào chưa phát triển ý nghĩa nhất định này (có lẽ chưa). Cũng có khả năng là anh ta không quan tâm vì lý do này hay lý do khác. Bạn cần phân tích toàn bộ tình huống, liệu anh ấy có hạnh phúc trong công việc của mình không. Nếu không thì có lẽ bạn nên làm gì đó để giúp anh ấy trước.

Nếu anh ta ổn với công việc nhưng chưa gặp phải nguy cơ của các trường hợp cạnh thì bạn có thể bắt đầu giáo dục anh ta. Nếu anh ấy nghiêm túc, anh ấy có thể thay đổi cách thức theo thời gian. Mặc dù tôi nghi ngờ về điều này nhưng bạn vẫn có thể thử.

Tuy nhiên, nếu anh ta trở thành kiểu người không giỏi trong các vụ kiện cạnh thì bạn có thể không còn gì khác ngoài việc loại anh ta ra khỏi đội. Đặc tính này là cần thiết để lập trình thực tế. Đáng buồn thay, không có nó thậm chí một người tuyệt vời sẽ không tạo ra công việc tốt.

Bạn có thể thực hiện đánh giá mã hoặc đánh giá thiết kế sớm hơn trong quá trình này không?

Dạy anh ta lập trình thử nghiệm trước. Cặp với anh. Bạn sẽ viết các trường hợp kiểm tra và anh ta sẽ viết mã để vượt qua các bài kiểm tra.

Có thể khiến QA tham gia đủ sớm vào việc phát triển tính năng giúp cung cấp cho anh ta một danh sách các trường hợp cạnh gần đầu để giải quyết? Mặc dù một số người có thể thấy điều này là không mong đợi nhà phát triển bao gồm tất cả mọi thứ, đây có thể là một cách để giải quyết vấn đề này nếu anh ta có xu hướng bỏ lỡ những trường hợp ranh giới mà một người thử nghiệm có thể bắt được ban đầu.

Ý tưởng khác tôi có ở đây là làm thế nào để anh ấy thấy vấn đề này. Là anh ta thực sự khó chịu và đánh dấu vào chính mình cho mô hình này hoặc anh ta chỉ xem điều này là bình thường và không phải là một cái gì đó để anh ta lo lắng trong việc giải quyết? Cấp điều này không đòi hỏi rất nhiều sự tin tưởng và khiến anh ta cởi mở trong quan điểm của mình nhưng tôi nghĩ rằng có một mức độ đồng cảm ở đây có thể giúp đỡ nếu bạn có thể nhìn mọi thứ từ quan điểm của anh ta.

Có vô số trường hợp cạnh, bao gồm tất cả chúng là không thể. Nếu ai đó làm #define TRUE FALSEgì? Nó thêm trường hợp cạnh, bạn cũng sẽ kiểm tra chúng?

Ngoài ra, tôi sẽ không xem xét việc đánh lừa mọi chức năng của một lớp riêng hoặc chức năng bên trong.

Cách tiếp cận tôi chọn cho mã phải rất chắc chắn và ổn định là:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

Bằng cách này, bạn có được các bãi chứa ứng dụng vững chắc trong QA và vào thời điểm bạn phát hành, ứng dụng này rất chắc chắn và an toàn.

Làm việc xung quanh lỗi là xấu. Ok, bạn có thể lưu một hàm nếu xử lý tệp là null và trả về null, nhưng trong hầu hết các trường hợp, có lỗi thiết kế ở đâu đó và sự cố ứng dụng là cách tốt hơn để buộc bạn tìm ra nguyên nhân. Hầu hết các trường hợp cạnh chỉ che giấu lỗi bằng cách ẩn một vấn đề, nói - nút ngừng hoạt động. Crash cho bạn biết rằng một số giả định về sản phẩm là sai và bạn phải xem lại logic đã gây ra sự cố.

Nếu nó là một trường hợp cạnh, nó thậm chí cần phải được xem xét? Nếu các trường hợp cạnh là quan trọng thì các trường hợp cạnh cần được đưa vào câu chuyện yêu cầu / tính năng / người dùng.

Nếu các trường hợp cạnh đã được coi là một phần của một phần công việc và các thiết bị được yêu cầu phải được đặt đúng chỗ thì chúng phải là một phần của mục công việc và theo định nghĩa, mục công việc không hoàn thành cho đến khi cơ chế xử lý trường hợp cạnh là tại chỗ

Điều này mang lại cho bạn với tư cách là Trưởng nhóm để kiểm tra lại sau khi công việc hoàn thành trong quá trình thảo luận công việc và nó mang lại cho nhà phát triển thứ gì đó để kiểm tra lại khi anh ta hoàn thành công việc.

Bắt các trường hợp cạnh là lý do tại sao QA tồn tại. Các lập trình viên có trách nhiệm đẩy công việc ra một cách kịp thời. Dành tất cả thời gian của họ để tìm kiếm các trường hợp cạnh là rất không hiệu quả. Nếu bạn có một chu kỳ lặp khá nhanh, thì điều này sẽ không có vấn đề gì cả. Trường hợp cạnh là gần vô hạn về số lượng. Nếu đó là một vấn đề với các trường hợp "cốt lõi" thì tôi sẽ có một chút lo ngại. Giống như các nhà phát triển là chuyên gia phát triển, một người thử nghiệm nên là một chuyên gia về thử nghiệm. Khi một người kiểm tra tìm thấy một vấn đề, họ gửi nó trở lại để phát triển. Các nhà phát triển khắc phục vấn đề. Vấn đề được giải quyết. Thời gian để một nhà phát triển theo dõi mọi trường hợp cạnh dài hơn rất nhiều so với chu kỳ kiểm tra lặp đi lặp lại. Cũng lưu ý, khi tôi nói về kiểm tra, tôi không có nghĩa là kiểm tra đơn vị hộp trắng, mà là kiểm tra hộp đen nghiêm ngặt.

Đó là một trong những trường hợp mà tôi tin rằng sự phát triển dựa trên thử nghiệm được giải cứu bởi vì nó giúp suy nghĩ về các trường hợp cạnh và bất cứ điều gì có thể phá vỡ mã.