Đánh giá mã tiến bộ và thực hành kiểm tra đơn vị

Là trưởng nhóm quản lý một nhóm các nhà phát triển không có kinh nghiệm (và không cần) trong việc xem xét mã và kiểm tra đơn vị, làm thế nào bạn có thể tiến hành đánh giá mã và thực hành kiểm thử đơn vị?

Làm thế nào bạn sẽ tạo ra một cách để đánh giá mã và kiểm tra đơn vị phù hợp một cách tự nhiên với luồng của nhà phát triển?

Một trong những trở ngại của hai lĩnh vực này là "chúng tôi luôn chặt chẽ về dòng thời gian, vì vậy không có thời gian để xem xét mã và kiểm tra đơn vị".

Một kháng cự khác để xem xét mã là chúng tôi hiện không biết làm thế nào để làm điều đó. Chúng ta có nên xem lại mã theo mỗi lần đăng ký hoặc xem lại mã vào một ngày được chỉ định không?

Các thành viên trong nhóm của bạn có thực sự đồng ý rằng các đánh giá mã và kiểm tra đơn vị là Những điều tốt, chỉ là không có thời gian cho những điều này?

Hay họ chỉ cố gắng từ chối ý tưởng với cái cớ này?

Trong trường hợp đầu tiên, giải pháp là bắt đầu thực hiện ngay . (OK, nếu bạn đang ở những ngày cuối cùng trước một cột mốc quan trọng, có lẽ bạn có thể đợi đến sau - nhưng không còn nữa.) Chúng tôi đã gặp tình huống đó ở nơi làm việc trước đây của tôi, nơi tôi là Kỹ sư chất lượng, chịu trách nhiệm cải thiện các hoạt động mã hóa và chất lượng tổng thể. Chúng tôi tiếp tục trì hoãn việc bắt đầu đánh giá mã cho đến tuần sau. Một ngày, tôi nhận ra rằng chúng tôi đã làm điều này trong một tháng hoặc lâu hơn, và có lẽ sẽ tiếp tục cho đến hết thời gian trừ khi tôi thử một cái gì đó khác biệt. Vì vậy, tôi đã công bố đánh giá mã đầu tiên cho tuần đó. Tôi đã nói với các bạn "không có vấn đề gì nếu nó không hoàn hảo, hoặc nếu chúng ta chưa biết chính xác nên làm gì - chúng ta sẽ bắt đầu thực hiện nó, xem cách nó diễn ra và cải thiện mọi thứ khi chúng ta học". Nó làm việc, ít nhất là cho đến khi tôi rời công ty.

Trong trường hợp thứ hai, bạn có thể cần giáo dục nhiều hơn và thảo luận cởi mở với nhóm. Thảo luận về các vấn đề về chất lượng mã, hỏi họ xem họ gặp vấn đề gì trong quá trình phát triển (hoặc thiếu) / trong mã / thử nghiệm, v.v. Và cùng nhau suy nghĩ về cách giải quyết những vấn đề này . Mục đích cuối cùng không nhất thiết là thực hiện đánh giá mã - chúng chỉ là phương tiện, trong khi mục tiêu là cải thiện quá trình phát triển và chất lượng đầu ra của nó. Nó cũng có thể chỉ ra rằng có những vấn đề khác, đau đớn hơn có thể được cải thiện dễ dàng hơn, mang lại nhiều lợi ích nhanh hơn; sau đó lấy những cái này trước Chúng thậm chí có thể là những thay đổi nhỏ trong môi trường hoặc quá trình; tất cả những điều này sẽ cải thiện tinh thần đồng đội, xây dựng niềm tin lẫn nhau và giúp liên kết nhóm.

Điểm mấu chốt là, bạn không thể ép buộc chất lượng lên bất kỳ ai - bạn chỉ có thể loại bỏ những trở ngại trong việc tạo ra chất lượng . Bằng cách thực thi các quy tắc nghiêm ngặt và thực hành bắt buộc mà không có sự đồng thuận của nhóm trước , bạn có thể xa lánh nhóm và cuối cùng ngăn chặn sự cải thiện chất lượng mà bạn đang hướng tới. OTOH bằng cách thảo luận mở và hướng đến thỏa thuận về những vấn đề cấp bách nhất đối với nhóm là gì và làm thế nào để cải thiện tình hình, bạn có nhiều khả năng nhận được hỗ trợ của nhóm. Điều này sẽ tạo ra một sự khác biệt quan trọng trong việc theo kịp các ổ đĩa cải tiến chất lượng trong thời gian dài.

Vấn đề kinh điển. Không bao giờ đủ thời gian để làm điều đó đúng, luôn luôn đủ thời gian để làm lại công việc. Cho đến khi mọi người bắt đầu thực hiện các thực hành tốt nhất, dường như sẽ không bao giờ có đủ thời gian để thực hiện các thực tiễn tốt nhất. Đặc biệt vì những chiến thắng là vô hình với những người bên ngoài phát triển.

Chìa khóa để xem lại mã là bạn muốn xem lại càng ít mã càng tốt, càng sớm càng tốt. Bằng cách đó, sẽ dễ dàng hơn để có thời gian xem xét nó, mã mới trong tâm trí của mọi người và việc thực hiện các cải tiến được đề xuất sẽ dễ dàng hơn. Trong cực kỳ bạn muốn xem xét mỗi lần đăng ký. Một công cụ tốt để tự động hóa việc này là http://code.google.com.vn/appengine/articles/rietveld.html . Đây là một biến thể của công cụ mà Google sử dụng nội bộ để buộc xem xét mã xảy ra với mỗi lần đăng ký.

Thách thức của đánh giá mã đã được mô tả từ nhiều thập kỷ trước trong cuốn Tâm lý học lập trình máy tính cổ điển . Vấn đề là các lập trình viên có xu hướng gắn hình ảnh bản thân của họ với các kỹ năng lập trình của họ. Điều đó có nghĩa là bất cứ lúc nào các lập trình viên phải đối mặt với bằng chứng cho thấy các kỹ năng của họ không phải là để hít vào, có xu hướng mang nó cá nhân. Điều này có thể gây ra xung đột nghiêm trọng. Nếu bạn chọn Phát triển nhanh cổ điển của Steve McConnell, ông sẽ đưa ra một số gợi ý về cách thiết lập quy trình xem xét mã nhằm giảm tỷ lệ xảy ra xung đột đó. (Một yếu tố quan trọng là đảm bảo rằng quản lý không bao giờ có bất kỳ sự tham gia nào vào quy trình.) Lưu ý rằng điều này làm giảm tỷ lệ xung đột, nhưng không ngăn ngừa xung đột xảy ra.

Điều đó nói rằng, lợi ích vượt xa các chi phí. Chỉ cần trích dẫn một số liệu, IBM đã thấy rằng đánh giá mã là đồng đô la là cách hiệu quả nhất để tìm và loại bỏ lỗi. Điều này không thay thế bộ phận QA của bạn bằng bất kỳ phương tiện. Nhưng nó dẫn đến kết quả là rất ít vấn đề để họ tìm thấy. Và đó là trước khi bạn nhận được những lợi ích liên quan đến việc nó tăng tốc độ học tập, truyền bá kiến ​​thức, v.v.

Đừng cho họ lựa chọn. Thực hiện kiểm tra và đánh giá bắt buộc. Nếu họ không hợp tác, bạn có thể sử dụng một số chiến thuật cứng rắn như từ chối các chương trình khuyến mãi chưa được kiểm tra hoặc chưa được xem xét. Nếu mọi thứ thực sự tồi tệ, hãy sa thải kẻ phạm tội tồi tệ nhất của bạn.

Tôi đã thấy các trường hợp một đội luôn bị chậm tiến độ bởi vì họ luôn sửa các lỗi đáng lẽ phải bị bắt bởi kiểm tra và đánh giá. Một chút công việc lên phía trước sẽ tiết kiệm nhiều hơn trong thời gian dài và bạn càng sớm đưa nhóm của mình vào hàng, nhóm của bạn sẽ nhận được càng tốt.

Thật không may, điều này có thể mất thời gian để thực sự thấy kết quả. Để khuyến khích thực hành, bạn có thể bắt đầu lập biểu đồ tỷ lệ báo cáo lỗi, thời gian trung bình để sửa lỗi và tốc độ thực hiện tính năng. Tôi thường thấy rằng sau khoảng sáu tháng thử nghiệm và đánh giá, những số liệu đó sẽ được cải thiện và nhóm của bạn cuối cùng sẽ có được nó.

Giới thiệu tdd chống lại ý chí của các nhà phát triển là khác nhau. Đó là một cách khó để học cách yêu tdd.

Vì tdd có hiệu quả nhất trong một lĩnh vực màu xanh lá cây (hoặc khó, tốn kém, không hiệu quả nếu các bài kiểm tra bị xóa sau khi kết thúc), tôi sẽ bắt đầu với một nhóm nhỏ thực hiện một cái gì đó mới. Nếu bạn tìm thấy hai develloppers trong nhóm ít đối lập với tdd hơn những người khác thì đó là điểm khởi đầu tốt. hãy nhớ rằng năng suất của các nhà phát triển tdd sẽ bị ảnh hưởng trong khi họ không có kinh nghiệm với tdd.

Sự phát triển tdd này là một điểm khởi đầu tốt cho một codereview. Thảo luận về cách các tdd ảnh hưởng đến kiến ​​trúc chương trình và làm thế nào nó giảm bớt sự mềm yếu.