Cách thuyết phục đồng đội sử dụng TDD [đã đóng]

Tôi là người duy nhất trong nhóm của tôi sử dụng TDD. Làm thế nào để tôi làm cho họ sử dụng nó?

Tôi bực mình vì khi tôi kéo, mã của ai đó sẽ phá vỡ các bài kiểm tra của tôi và tôi là người phải sửa chúng.

Việc sử dụng github, fork và pull request sẽ giải quyết vấn đề này, để họ cần vượt qua bài kiểm tra trước khi kéo được chấp nhận?

Tôi không phải là người quản lý dự án và dường như tôi không thể thuyết phục cô ấy sử dụng nó.

Cách tôi nhìn thấy, cách duy nhất để thuyết phục mọi thứ về các bài kiểm tra là chứng minh rằng chúng hữu ích - tức là các bài kiểm tra thất bại giúp tìm và sửa lỗi .

Cách bạn mô tả vấn đề mặc dù, có vẻ như đây không phải là trường hợp ở đây. Nhìn...

... Khi tôi kéo, mã của ai đó sẽ phá vỡ các bài kiểm tra của tôi và tôi là người phải sửa chúng.

Nếu tôi hiểu chính xác, bạn có nghĩa là bạn phải sửa đổi các bài kiểm tra. Chà, điều đó không có vẻ như lỗi thử nghiệm giúp tìm và sửa lỗi phải không? Nếu các bài kiểm tra không giúp tìm ra lỗi, thì đó là vị trí khá yếu để bắt đầu thuyết phục đồng nghiệp của bạn - họ có thể mong đợi gì để đạt được? sửa lỗi tẻ nhạt trong mã kiểm tra dễ vỡ?

Điều này nghe có vẻ như là một ngõ cụt, nhưng nó thực sự không. Mục tiêu cuối cùng của bạn (thuyết phục cho TDD) vẫn có ý nghĩa khá tốt, đừng bỏ nó. Chỉ cần tập trung lại nỗ lực của bạn để loại bỏ những trở ngại bạn phát hiện ra.

Thử nghiệm thất bại làm phiền bạn bây giờ về cơ bản là "cảnh báo sai" - có nghĩa đây là những lỗi trong các thử nghiệm không có trong mã. Sử dụng chúng như một cơ hội để cải thiện các bài kiểm tra, để tìm hiểu làm thế nào để thiết kế thử nghiệm đáng tin cậy tốt. Làm việc trên các thử nghiệm để làm cho "cảnh báo sai" ít thường xuyên hơn và để dễ dàng phát hiện ra các lỗi thực sự trong mã được kiểm tra.

Khi bạn phát hiện ra các lỗi thực sự, hãy cho đồng nghiệp của bạn biết và giúp họ khắc phục - và đừng quên chỉ ra rằng các lỗi này được tìm thấy trong các thử nghiệm của bạn. Điều đó sẽ làm cho một nền tảng thực sự vững chắc để thuyết phục các đồng nghiệp của bạn.

Điều đáng nói là các kỹ năng thiết kế thử nghiệm mà bạn phát triển ở giai đoạn "sơ bộ" có thể sẽ cần thiết một lần nữa, nếu (khi :) bạn cuối cùng đã thuyết phục được đồng đội của mình sử dụng TDD. Nghĩ về nó...

... Điều gì sẽ xảy ra khi phát triển theo hướng kiểm tra được giới thiệu cho các đồng nghiệp thiếu kinh nghiệm của bạn?

Điều đầu tiên mong đợi là các chàng trai sẽ bắt đầu viết các bài kiểm tra tào lao và (kinh dị!) Thậm chí phá vỡ những bài kiểm tra tốt trong khi học. Để giúp họ tìm ra cách thực hiện đúng, bạn sẽ cần một sự hiểu biết vững chắc về thiết kế thử nghiệm tốt.

Tất cả các lỗi bạn tìm thấy và sửa chữa trong các bài kiểm tra của bạn bây giờ, sẽ được lặp đi lặp lại bởi tất cả các đồng đội của bạn khi họ bắt đầu học. Nếu (khi!) Điều đó xảy ra, tốt nhất bạn nên chuẩn bị nhanh chóng và giải thích rõ ràng cách cải thiện nếu bạn muốn họ duy trì tích cực về TDD.

Khi tôi muốn khuyến khích việc sử dụng Phát triển dựa trên thử nghiệm, tôi đã chạy một Cyber-Dojo . Với loại bài tập này, sự nhấn mạnh không phải ở bản thân mã, mà là quá trình viết mã .

Chúng tôi đã dành một buổi chiều, theo cặp, lặp lại cùng một kata, nhưng trong các điều kiện khác nhau. Chúng tôi bắt đầu với tất cả các nhóm thực hiện một bài tập cùng một lúc. Điều này cung cấp một đường cơ sở.

Sau đó chúng tôi đã thảo luận về một số nguyên tắc cơ bản của TDD, mọi người đã thay đổi đối tác và lặp lại cùng một kata. Chúng tôi lặp lại cùng một kata để nhấn mạnh việc tạo mã và thay vào đó tập trung mọi người vào quá trình đặt tên các trường hợp thử nghiệm và chu trình Đỏ / Xanh lục.

Sau đó, chúng tôi lặp lại kata một lần nữa, nhưng cứ sau 10 phút, một người trong mỗi nhóm sẽ chuyển sang một nhóm khác, mô phỏng môi trường nhóm khá trôi chảy mà chúng ta thường thấy trong những ngày này.

Trong lần lặp lại cuối cùng, chúng tôi đã có cả hai đối tác thay đổi cứ sau 10 phút hoặc lâu hơn thành các nhóm khác nhau. Điều này giúp chứng minh rằng với TDD, ngay cả việc chuyển giao từ một nhóm sang một nhóm hoàn toàn khác không nhất thiết phải quá đau đớn, vì dự án chỉ nên thực hiện một chu kỳ Đỏ / Xanh.

Điều thú vị là, có rất ít người đã thực hiện bất kỳ TDD nào trước phiên, nhưng những kiến ​​thức về TDD đã được lan truyền nhanh chóng cho đến khi lặp lại cuối cùng thông qua kata, hầu hết mọi người đều nghĩ theo cách TDD hoặc ít nhất có thể đánh giá cao lý do tại sao có thể có lợi

Mọi người thường nói rằng buổi chiều vừa vui vừa bổ ích và hiện chúng tôi đang xem xét các cách khác để sử dụng Cyber-Dojo tại nơi làm việc của tôi.

Cyber-Dojo , được viết bởi Jon Jagger , hoạt động cực kỳ tốt cho loại bài tập này. Đây là một trang web dựa trên môi trường tích hợp để thực hiện cố ý thực hành của TDD và tìm hiểu về động lực nhóm. Nó có rất nhiều kata được chọn đặc biệt để giúp mọi người tập trung vào quá trình TDD chứ không phải vấn đề. Nó cũng hỗ trợ một loạt các ngôn ngữ, từ Python và Ruby đến Java và C ++.

Điều tốt nhất là, sau khi thực hiện một kata, bạn có thể quay lại và xem tiến trình màu đỏ / xanh lá cây (hoặc có thể không * 8 ') của mỗi nhóm tham gia. Nó của đèn giao thông là một cách tuyệt vời để hình dung như thế nào quá trình TDD hoạt động.

Nếu bạn muốn máy chủ CyberDojo của riêng mình, toàn bộ dự án có thể được tìm thấy tại github và thậm chí còn có một máy ảo thiết bị Turnkey Linux được liên kết từ đó, có nghĩa là giả sử bạn đã cài đặt trình phát VMware hoặc VirtualBox , bạn có thể cài đặt và chạy trong Một vài phút tải xuống thiết bị!

Nếu họ chống lại TDD, nó là ok. Nhiều người (bao gồm cả bản thân tôi) đang gặp vấn đề với việc viết bài kiểm tra đơn vị trước tiên.

Tuy nhiên, bạn nên đặt ra một câu hỏi về việc không có bài kiểm tra đơn vị nào cả, và vấn đề kiểm tra đơn vị bị phá vỡ. Các thử nghiệm đơn vị là một mạng lưới an toàn ngăn chặn rất nhiều lỗi có thể xảy ra và cho phép tái cấu trúc mã. Giải thích về chất lượng mã cao hơn và mã sạch hơn.

Tôi nghĩ tốt nhất là tìm một video giải thích các lợi thế của việc sử dụng TDD và hiển thị nó trong một cuộc họp.

Nếu cô ấy không chịu lắng nghe, thì bạn có thể cố gắng đi đến một người nào đó phía trên cô ấy, nhưng điều đó có thể không thông minh lắm nếu sếp của bạn quá cứng đầu.

Thật khó để thuyết phục mọi người thay đổi thói quen của họ, nhưng đây là một số điều bạn có thể thử:

• Nói chuyện với các nhà phát triển khác và giải thích cho họ tại sao bạn nghĩ TDD là một ý tưởng tốt.
• Thuyết phục họ (hoặc ít nhất là một số trong số họ) để thử nó trong một thời gian giới hạn
• Cố gắng thiết lập một số yêu cầu tối thiểu để làm việc tốt như một nhóm. Họ không nhất thiết phải làm TDD, nhưng chắc chắn họ không nên kiểm tra mã bị lỗi bài kiểm tra đơn vị. Đây là một vấn đề riêng biệt hơn là thuyết phục họ sử dụng TDD, và quan trọng hơn nhiều để giải quyết.
• Cố gắng thuyết phục ban quản lý để thực thi một thời gian dùng thử cho TDD. Bạn sẽ phải sẵn sàng cung cấp một số bằng chứng về lý do tại sao đây là một thực tiễn tốt và làm thế nào nó sẽ tiết kiệm thời gian và tiền bạc của công ty trong tương lai.

Nếu không có cái nào trong số này hoạt động cả, bạn có thể muốn xem xét làm việc ở một nơi khác. Có rất nhiều công ty khác mà cuộc sống của bạn sẽ dễ dàng hơn đáng kể.

Có 2 vấn đề hơi khác nhau ở đây: khiến mọi người làm TDD và mọi người phá vỡ bài kiểm tra của bạn.

Tôi không chắc chắn về vấn đề đầu tiên, cá nhân tôi thấy đó là một cách làm việc giả tạo và không phù hợp với tất cả các loại hình phát triển. Tôi là tất cả để có một bộ kiểm thử đơn vị tốt, nhưng tôi thường thấy viết mã hiệu quả hơn trước và sau đó là kiểm tra, vì trong khi viết mã, ý tưởng của tôi luôn thay đổi và cũng lãng phí thời gian viết bài kiểm tra sớm (IMO).

Về vấn đề thứ hai, hãy thiết lập dự án để các bài kiểm tra đơn vị được chạy khi đăng ký, để các nhà phát triển khác không có lựa chọn nào khác ngoài việc biết họ đã phá vỡ một bài kiểm tra.

Như đã nói trong rất nhiều câu "tôi nên thuyết phục X sử dụng phương pháp / công nghệ Y" như thế nào, câu trả lời của tôi luôn giống nhau: ví dụ.

Sử dụng nó và có kết quả tốt hơn (mesurable). Sau đó hãy chắc chắn rằng những người khác chú ý.

Trên một dự án hiện có, bạn không. Nó giống như khi bạn thực hiện các thay đổi về cách đặt dấu ngoặc nhọn trong mã kế thừa vì bạn không thích kiểu thụt lề.

Rất nhiều lời khuyên tốt. Và bây giờ, một chút nữa ...

Bạn phải giành được trái tim và khối óc (WHAM) mỗi lần một Luddite . Quên về việc buộc nó xuống cổ họng của họ. Rất nhiều bài học đối tượng trong một khoảng thời gian không xác định (xin lỗi về điều đó). Cuối cùng, bạn sẽ đạt được một khối lượng quan trọng, thuyết phục (các) người "đúng".

Sự nhiệt tình và liên tục của bạn đối với TDD là rất quan trọng trong một chiến dịch WHAM.

Bạn phải biến việc phá vỡ thử nghiệm và thay đổi mã thành những khoảnh khắc có thể dạy được, những bài học quan trọng đối với người đồng mã hóa của bạn. Làm cho nó cá nhân. IE Họ có quan tâm đến danh tiếng về việc cung cấp mã sạch trên trung bình không? Họ có quan tâm đến việc quản lý rách rưới cho họ về mã hiện đã trễ vì những người kiểm thử tích hợp đã cho họ kiểm tra thực tế không? Jack có mong muốn sửa đổi một số mã khó khăn nhưng sợ tác dụng phụ?

Thu thập các ví dụ tốt về phá vỡ thử nghiệm như bẫy lỗi do coder gây ra. Các lập trình viên sẽ thấy các thử nghiệm thay đổi là công việc không cần thiết đối với mã không liên quan; họ phải hiểu rằng các bài kiểm tra chỉ bao gồm mông của họ.

Tìm một số mã có ý nghĩa toàn cầu (một số phương pháp tiện ích đơn giản), xây dựng một số thử nghiệm, sau đó chứng minh rằng các thử nghiệm cho phép thay đổi nỗi sợ động đất trong suốt ứng dụng. Và tôi có nghĩa là để nhấn mạnh vấn đề tình cảm quá!

Tập hợp một số ví dụ mã thời gian đơn giản để làm sạch (nghĩa là được đưa vào sản xuất) và chứng minh rằng mặc dù đã nỗ lực thêm để mã hóa thử nghiệm , chúng tôi đã hoàn thành nhanh hơn và với chất lượng cao hơn.

Cảnh báo: TDD không phải là thuốc chữa và không thể khắc phục thiết kế và mã hóa OO xấu (nhưng chắc chắn nó có thể phơi bày nó). Đừng để Luddites đổ lỗi cho nỗ lực mã thử nghiệm cho sự bất tài của họ.

Tôi sẽ thử lại để thuyết phục người quản lý. Từ những gì bạn đã viết, tôi không nghĩ bạn có thể thuyết phục các đồng đội của mình làm TDD sau lưng cô ấy.

Bạn phải nói ngôn ngữ của cô ấy. Người quản lý có xu hướng không ấn tượng với công nghệ, nhưng họ hiểu ngôn ngữ kinh doanh:

• kiểm tra sẽ tiết kiệm thời gian trong quá trình phát triển, vì thay vì kiểm tra thủ công (cố gắng tái tạo lỗi cục bộ, chơi với bảng điều khiển rails ...), bạn sẽ tự động chạy thử nghiệm

• kiểm tra sẽ tiết kiệm rất nhiều thời gian trong quá trình bảo trì ứng dụng, khi bạn có thể dễ dàng phát hiện lỗi bất cứ khi nào bạn thay đổi điều gì đó. Giải thích rằng các bài kiểm tra đòi hỏi đầu tư ban đầu cao hơn, nhưng họ sẽ tự trả tiền trong thời gian dài (việc duy trì các bài kiểm tra tốt thường nhanh chóng và dễ dàng)

• và bạn sẽ làm gì với thời gian thêm? tạo công cụ moar và làm cho họ kiếm tiền moar :)

Đối với các lập trình viên, hãy thử lập luận này (nó hoạt động với tôi, ngược lại): "Dù sao bạn cũng đang kiểm tra mã, có hoặc không có TDD. Chỉ có bạn làm điều đó bằng tay thay vì tự động hóa nó. Các nhà phát triển thông minh tự động hóa càng nhiều càng tốt. "

Trong các dự án thực tế với thời hạn, mọi người muốn tập trung vào việc hoàn thành công việc với những gì họ biết. Đó chỉ là bản chất của con người. Và nếu bạn chưa bao giờ học TDD, bạn sẽ giống như cô ấy trong tình huống này. Tôi đoán nó.

Tại sao đám đông thu gom rác lại yêu thích, học hỏi và sống RAII? Làm thế nào bạn có thể vô địch quản lý bộ nhớ tự động nhưng giữ vững cách quản lý lỗi thời cho các tài nguyên chung như tệp, kết nối, v.v? Bởi vì RAII là một công nghệ mà họ không biết, không hiểu và không có thời gian để sử dụng khi họ có thời hạn cần hoàn thành công việc.

Tôi cá là bạn không sử dụng RAII và không sẵn sàng tìm hiểu và hiểu nó cho dự án hiện tại của bạn. Giống như đồng nghiệp của bạn, người không sẵn sàng học và hiểu TDD.