Kệ TFS và Đánh giá mã

Question

Một trong những lý do để sử dụng các kệ TFS là để xem xét mã mà tôi không đồng ý, nhưng đây là thực hành được tuân thủ trong dự án hiện tại của tôi. Lý do tôi thấy bằng cách sử dụng giá sách TFS không phải là ý tưởng tốt để xem xét mã là

• Kệ không có thứ tự tự nhiên làm bộ thay đổi. Điều này có thể dẫn đến nhiều xung đột hợp nhất.
• Nếu nhà phát triển không thể kiểm tra mã cho đến khi được xem xét, nó sẽ phụ thuộc vào người đánh giá và nếu người đánh giá không đánh giá trong khoảng thời gian ngắn, các kệ có thể can thiệp vào các tác vụ khác.
• Cộng tác với các nhà phát triển khác trở nên đau đớn vì bây giờ bạn cần phải vượt qua các kệ sách thay vì mã kiểm tra, điều này có thể gây ra xung đột hợp nhất trong tương lai.

Ai đó có thể cung cấp cho tôi một số gợi ý mà có thể là cho hoặc chống TFS shelveset cách tiếp cận để đánh giá do đó, hoặc tôi nhận được thuyết phục về cách tiếp cận hoặc tôi có thể trình bày một trường hợp không sử dụng phương pháp này?

Answer 1

Tôi nghĩ rằng Microsoft không đồng ý với bạn rất nhiều trên thế này, như tính năng Mã xét mới trong TFS 11 và Visual Studio 11 được xây dựng xung quanh shelvesets. Vấn đề thực sự có lẽ là nhiều hơn về cách thức hoạt động của nhóm và cách phân chia nhiệm vụ trên sản phẩm.

Nếu các tác vụ đã được phân chia sao cho chúng có ít sự phụ thuộc và sao cho những người làm việc trong cùng một khu vực làm việc chặt chẽ với nhau thì bạn sẽ không gặp bất kỳ vấn đề nào về việc hợp nhất và đăng ký. Nếu bạn có nhiệm vụ dành nhiều thời gian hơn, sau đó thường xuyên lấy phiên bản mới nhất từ ​​chi nhánh phát triển để bạn luôn có mặt.

Nếu bạn thấy Người đánh giá quá chậm và các giá xếp chồng lên nhau, tất cả đang chờ được xem xét, thì đây là nơi các vấn đề thực sự khác có thể xảy ra. Khi một công việc được hoàn thành, nó sẽ được xem xét càng sớm càng tốt và không nằm xung quanh chờ đợi để được xem xét. Nếu đánh giá mất nhiều thời gian hơn 24h thì điều này có thể trở thành vấn đề thực sự. Bạn có thể làm giảm bớt điều này bằng cách thực hiện đánh giá ngang hàng bởi người khác hoặc bằng cách nhận được nhiều người đánh giá hơn trong nhóm.

Nếu vẫn thất bại, bạn có thể thực hiện các đánh giá sau giết mổ (xem lại các thay đổi thay vì giá), TFS 11 và Visual Studio 11 hỗ trợ kịch bản này.

Sở thích cá nhân của tôi là tin tưởng các nhà phát triển trong nhóm của tôi và do đó chúng tôi chủ yếu thực hiện các đánh giá sau khi đăng ký. Nếu chúng ta có thành viên mới hoặc rất thành niên, thì tôi sẽ đảm bảo rằng một nhà phát triển cao cấp hơn có sẵn để thực hiện đánh giá trước khi đăng ký đầu tiên thay thế.

Xem thêm:

• http://blog.jessehouwing.nl/2012/03/did-you-miss-my-techdaysnl-talk-on-code.html
• https://blogs.msdn.com/b/ivo_manolov/archive/2010/11/29/10097641.aspx?Redirected=true

Answer 2

Không quá nhiều kệ sách đó là vấn đề. Nếu bạn đang chờ đợi trên một peer để xem xét mã của bạn, cách mã được lưu trữ sẽ không tạo ra nhiều sự khác biệt. Điều đó nói rằng, các kệ được lưu trữ an toàn ra khỏi máy tính của bạn ở một vị trí có thể truy cập bởi các nhà phê bình, vì vậy tôi nghĩ rằng đó là một giải pháp tốt như bất kỳ. Lựa chọn thay thế sẽ là kiểm tra, vượt qua các changeset và hoàn nguyên nếu nó không vượt qua cơ bắp hoặc vượt qua một zip? Cả hai đều có những hạn chế đáng kể.

Vì vậy, là câu hỏi thực sự cho dù bạn có yêu cầu đánh giá mã trước khi đăng ký không?

Answer 3

Giá không có thứ tự tự nhiên như bộ thay đổi. Điều này có thể dẫn đến nhiều xung đột hợp nhất.

Tôi không thể thấy điểm của bạn ở đây, "thứ tự tự nhiên" cho bạn là gì? Thứ tự thời gian của changesets không theo một thứ tự nhất định khi bạn bắt đầu làm việc trong một nhóm.

Nếu nhà phát triển không thể checkin đang cho đến khi nó được xem xét, đặt một sự phụ thuộc về người xem và nếu người xem không làm xét trong vòng một thời gian ngắn những shelvesets có thể cản trở các nhiệm vụ khác.

Một lần nữa, bạn có tình huống tương tự với "phát triển nhiệm vụ thường xuyên" không phải vì bạn bắt đầu một nhiệm vụ A trước một nhiệm vụ B mà bạn sẽ kiểm tra nhiệm vụ A trước B (trừ khi B phụ thuộc vào A, nhưng đó không phải là điểm ở đây). Xem xét xem xét như là bước cuối cùng của quy trình làm việc của phát triển nhiệm vụ. Sự phụ thuộc vào người đánh giá thực sự làm cho mọi việc trở nên phức tạp hơn một chút, nhưng đó là vì có một bản dựng ổn định và có mã tuân thủ các tiêu chuẩn của công ty.

Hợp tác với các nhà phát triển khác trở nên đau đớn như bây giờ bạn cần phải vượt qua shelveset xung quanh chứ không phải là checkin mã, mà lại có thể gây ra xung đột nhập trong tương lai.

Bạn có biết điều gì dễ hơn kệ sách không?Bạn có thích gửi email có mã đã sửa đổi trong tệp zip không? Kệ là cách dễ dàng hơn để chia sẻ mã giữa các nhà phát triển khi bạn không muốn tác động đến tham chiếu. Ở đây một lần nữa, tôi không thể nhìn thấy vấn đề xung đột hợp nhất mà bạn đề cập đến.

Dưới đây là một số lời khuyên:

1. Khi ai đó là nhận lại shelveset của dev khác, nói Dev Một tạo ra một shelveset và Dev B muốn để xem xét nó, hãy chắc chắn Dev B có một riêng biệt sạch sẽ và không gian làm việc chuyên dụng để unshelve. Bạn không muốn bỏ mọi thứ trong không gian làm việc "dev" thông thường của bạn. Một không gian làm việc chuyên dụng để xem xét mã dễ dàng giải quyết vấn đề xung đột hợp nhất mà bạn đã đề cập.

2. Về lý thuyết, mọi thứ cần được xem xét trước khi được tích hợp vào chi nhánh mục tiêu. Điều đó đang được nói, khó hơn trong thực tế để làm như vậy, do đó, không nhằm mục đích làm điều gì đó hoàn hảo nếu nhóm của bạn không có thói quen của quá trình như vậy. Nhà phát triển cấp cao biết rõ ứng dụng mà anh ấy đang làm việc có thể được ủy quyền để đăng ký trước khi xem xét. Đó là tất cả vấn đề của sự cân bằng, trong trường hợp này bạn có được sự linh hoạt và trải nghiệm dev mượt mà hơn nhưng tham chiếu của bạn có thể bị ảnh hưởng về chất lượng và sự ổn định. Không có người chiến thắng thực sự ở đây, đó là sự lựa chọn của bạn dựa trên những gì quan trọng đối với bạn.

3. Không sử dụng các chi nhánh để xem xét mã.

4. Tôi đồng ý trải nghiệm xem xét mã thông qua các kệ có phần không hoàn chỉnh trong VS/TFS, nhưng cách tốt hơn là các giải pháp thay thế. Microsoft nhận ra rằng họ có thể làm tốt hơn trong lĩnh vực này và nó dịch trong những cải tiến được thực hiện trong VS11/TFS11. Với phiên bản tiếp theo, bạn có trải nghiệm xem mã đúng, vẫn dựa trên giá sách nhưng có hệ thống giao tiếp hoàn chỉnh hơn giữa các diễn viên. Cải tiến này được thực hiện trong trải nghiệm "Công việc của tôi" và mọi thứ trở nên mượt mà hơn. Hãy thử tfspreview.com và VS11 beta hoặc đọc một số bài đăng trên blog (Brian Harry) để biết thêm thông tin. Dưới đây là a link bạn sẽ quan tâm.