Các lập trình viên giỏi nhất của bạn có nên kiểm tra mã của người khác để kiểm soát nguồn không?

Một trong những khác biệt giữa svn và git là khả năng kiểm soát truy cập vào kho lưu trữ. Thật khó để so sánh hai vì có một sự khác biệt về quan điểm về người nên được phép thực hiện các thay đổi!

Câu hỏi này là về việc sử dụng git làm kho lưu trữ tập trung cho một nhóm tại một công ty ở đâu đó. Giả sử rằng các thành viên của nhóm có trình độ kỹ năng khác nhau, giống như hầu hết các công ty.

Git dường như cho rằng các lập trình viên giỏi nhất (năng suất nhất, giàu kinh nghiệm nhất) của bạn đáng tin cậy để kiểm tra mã. Nếu đó là trường hợp, bạn đang dành thời gian của họ để thực sự viết mã để xem lại mã của người khác để kiểm tra nó. Điều này có thành công không? Tôi thực sự muốn tập trung câu hỏi này vào việc sử dụng tốt nhất thời gian của lập trình viên tốt nhất của bạn là gì, chứ không phải vào các hoạt động kiểm soát phiên bản tốt nhất nói chung . Một hệ quả có thể là, các lập trình viên giỏi có bỏ việc không nếu một phần đáng kể trong công việc của họ là xem xét mã của người khác? Tôi nghĩ rằng cả hai câu hỏi sôi nổi: đánh giá có xứng đáng với năng suất không?

Vì không rõ ràng từ câu hỏi của bạn, tôi chỉ muốn chỉ ra rằng một quy trình làm việc của người gác cổng không có nghĩa là cần thiết với git. Nó phổ biến với các dự án nguồn mở vì số lượng lớn người đóng góp không đáng tin cậy, nhưng không có ý nghĩa nhiều trong một tổ chức. Bạn có tùy chọn để cung cấp cho tất cả mọi người quyền truy cập nếu bạn muốn.

Điều mà mọi người đang bỏ qua trong phân tích này là các lập trình viên giỏi dành nhiều thời gian để xử lý mã bị hỏng của các lập trình viên khác. Nếu mọi người đều có quyền truy cập đẩy, thì bản dựng sẽ bị phá vỡ và các lập trình viên giỏi nhất có xu hướng là những người thường xuyên tích hợp và truy tìm thủ phạm khi mọi thứ bị phá vỡ.

Điều mà tất cả mọi người có quyền truy cập đẩy là khi một cái gì đó bị phá vỡ, tất cả những người kéo đều có một bản dựng bị hỏng cho đến khi cam kết vi phạm được hoàn nguyên hoặc sửa chữa. Với quy trình làm việc của người gác cổng, chỉ có người gác cổng bị ảnh hưởng. Nói cách khác, bạn chỉ ảnh hưởng đến một trong những lập trình viên giỏi nhất của bạn thay vì tất cả họ.

Nó có thể chỉ ra rằng chất lượng mã của bạn khá cao và tỷ lệ lợi ích chi phí của người gác cổng vẫn không xứng đáng, nhưng đừng bỏ qua các chi phí quen thuộc. Chỉ vì bạn đã quen với việc giảm năng suất không có nghĩa là nó không phát sinh.

Ngoài ra, đừng quên khám phá các tùy chọn lai. Thật dễ dàng với git để thiết lập một kho lưu trữ mà bất kỳ ai cũng có thể đẩy tới, sau đó có một người gác cổng như nhà phát triển cấp cao, người kiểm tra hoặc thậm chí một máy chủ tích hợp liên tục tự động quyết định xem và khi nào thay đổi sẽ biến nó thành kho lưu trữ thứ hai ổn định hơn. Bằng cách đó bạn có thể có được điều tốt nhất của cả hai thế giới.

Tôi đã làm việc tại một công việc mà việc đăng ký chỉ giới hạn ở các nhóm trưởng (và các trưởng nhóm không thể kiểm tra mã riêng của họ). Điều này phục vụ như là cơ chế của chúng tôi để thực thi đánh giá mã, phần lớn là do một số sự cố trong đó các cam kết xấu đã xâm nhập vào cơ sở mã ngay cả xung quanh các đăng ký kiểm tra và phân tích tĩnh.

Một mặt, nó đã làm việc đó. Một số cam kết xấu đã được tìm thấy trước khi chúng vào codebase (và ngay lập tức bị lãng quên trong một tuần hoặc lâu hơn cho đến khi ai đó vấp phải chúng). Điều này gây ra sự gián đoạn ít hơn trong codebase. Thêm vào đó, tôi có thể đẩy lùi một số thứ định dạng / cấu trúc trước khi chúng trở thành nợ công nghệ; bắt một số lỗi trước khi chúng trở thành lỗi Và nó mang lại cho tôi cảm giác tuyệt vời cho những gì nhóm của tôi đang làm.

Mặt khác, nó khiến tôi tự nhiên rơi vào những cơn thịnh nộ giết người khi thay đổi 3 dòng của tôi mất 4 giờ để thực hiện vì phải theo dõi một khách hàng tiềm năng khác và khiến họ thực hiện cam kết. Nó thúc đẩy tôi thực hiện các cam kết ít thường xuyên hơn nhiều so với thực tiễn tốt nhất và đôi khi dẫn đến các vấn đề cố gắng theo dõi các thay đổi đối với nhà phát triển đã thực hiện chúng.

Tôi thường không khuyên bạn nên ngoại trừ trong những môi trường cần thiết nhất. Thực hiện các đánh giá và cam kết thực sự không quá tệ. Có quá trình riêng của tôi phụ thuộc vào ý thích bất chợt của người khác mặc dù đã gây phẫn nộ. Nếu bạn không thể tin tưởng các nhà phát triển của mình để kiểm tra mã, hãy tìm các nhà phát triển tốt hơn.

Không ai có thể cam kết.

Nếu bạn gặp vấn đề với các lỗi được cam kết thì đó không phải là chính sách kiểm soát nguồn sai. Đó là các nhà phát triển không đảm bảo rằng những gì anh ấy / cô ấy cam kết hoạt động. Vì vậy, những gì bạn phải làm là xác định các hướng dẫn rõ ràng về những gì để cam kết và khi nào.

Một điều tuyệt vời khác được gọi là kiểm tra đơn vị;)

Có một sự thay thế mặc dù.

a) Nếu bạn sử dụng kiểm soát phiên bản phân tán, bạn có thể tạo một repos chính mà chỉ có thể thực hiện các yêu cầu kéo. Theo cách đó, tất cả các nhà phát triển có thể nhận phiên bản mã của riêng họ trong khi bạn có quyền kiểm soát chi nhánh chính.

b) Trong lật đổ và tương tự, bạn có thể sử dụng các nhánh trong đó mỗi dev phải tạo các bản vá để đưa nó vào nhánh chính.

Bạn nên xem qua các dự án như Gerrit , cho phép tất cả các nhà phát triển đẩy mã của họ vào chi nhánh 'xem xét' và một khi các nhà phát triển cấp cao / lãnh đạo hài lòng với những thay đổi này, họ có thể đẩy họ vào bản chính / phát hành.

Nếu họ không hài lòng, họ có thể để lại nhận xét bên cạnh một dòng mã, yêu cầu cập nhật bản vá, v.v.

Bằng cách này, bất kỳ ai có thay đổi đang chờ xử lý đều có thể lấy nó ngay khi sẵn sàng và chỉ những người đủ điều kiện (có đặc quyền +2 trong Gerrit) mới có thể đẩy mã đó để kiểm tra và sau đó được sản xuất.

Không, đó là một cách sử dụng kém tài năng tốt nhất của bạn. Hãy tưởng tượng một công ty xuất bản lấy các tác giả thành công nhất của họ và khiến họ thực hiện chỉnh sửa; ý xấu.

Cần có đánh giá mã, nhưng điều đó không có nghĩa là luôn luôn kiểm tra mã của jr. Cuối cùng, mọi người trong nhóm nên được mong đợi đạt đến cấp độ mà họ có thể đóng góp mã với hướng dẫn tối thiểu. Họ trải qua ba cấp độ tin cậy:

1. Không có - Tôi muốn xem mọi dòng mã trước khi bạn kiểm tra nó.
2. Một số - Hãy cho tôi biết những gì bạn đang làm và tôi sẽ cung cấp phản hồi
3. Hầu hết - Đi làm công việc của bạn và chỉ yêu cầu giúp đỡ khi cần thiết.

Ưu điểm của việc giải phóng tài năng của bạn:

• tập trung vào thiết kế
• tham gia vào việc thiết lập các tiêu chuẩn mã hóa và chiến lược thực thi (mà không tự làm tất cả)
• giải quyết các vấn đề mã hóa khó khăn
• cung cấp cố vấn (mà không cần phê duyệt mọi dòng mã)

Có những nhà phát triển quan tâm đến một con đường quản lý, những người có thể không muốn viết mã cả ngày; để những người khác một mình.

là đánh giá có giá trị năng suất đạt?

Nó phụ thuộc vào "sự cân bằng" của nhóm và vào cách đánh giá được thiết lập. Cả hai đều là vấn đề về quản lý và làm việc nhóm, không có phép thuật kiểm soát phiên bản (tập trung hoặc phân phối) nào có thể có ảnh hưởng đáng kể đến điều đó.

Nếu làm sai , năng suất đạt được tất nhiên sẽ giết chết mọi lợi ích của đánh giá; Câu trả lời là mặc dù không bỏ ý tưởng đánh giá mà tìm ra cách thực hiện đúng .

Một cách tiếp cận để tìm hiểu xem các đánh giá của bạn có ổn không là sử dụng công cụ theo dõi vấn đề để theo dõi thời gian dành cho đánh giá (một số công cụ đánh giá mã cũng cho phép điều đó). Nếu bạn phát hiện ra các đánh giá đang mất khá nhiều thời gian, hãy đầu tư một số nỗ lực vào việc tìm ra lý do và cách để cải thiện mọi thứ. Ngoài ra, sẽ không hại khi có các thành viên 1: 1 thường xuyên để khám phá các vấn đề tiềm ẩn với các đánh giá mã.

Nếu các lập trình viên "giỏi nhất" trong nhóm bị buộc phải dành hàng giờ để đào bới rác không thể hiểu được được tạo ra bởi các lập trình viên xảo quyệt, thì giải pháp là sa thải những người làm chuyện tào lao, không thu hút công nghệ VCS.

• ^{Trong một trong những dự án trước đây, tôi được chỉ định xem xét các thay đổi mã được thực hiện bởi thành viên nhóm hoạt động kém hiệu quả, trong một thành phần mất gần một giờ để xây dựng và chạy thử nghiệm. Tôi bắt đầu đọc các khác biệt và khi tôi nhận thấy một sự thay đổi không thể hoàn thành, tôi chỉ đơn giản là hoàn thành việc xem xét, đăng các bình luận cần thiết và yêu cầu quản lý để đảm bảo rằng các yêu cầu đánh giá tiếp theo đi kèm với xác nhận bằng văn bản rằng mã của họ biên dịch. Không có "yêu cầu xem xét" kể từ khi anh chàng rời đi.}

Mặt khác, khi nhóm được cân bằng hợp lý, đánh giá mã là niềm vui và giáo dục. Trong dự án trước đây của tôi, chúng tôi có yêu cầu xem xét mã 100% và nó không mất nhiều thời gian cũng như không gây mất tập trung. Có những lỗi được phát hiện thông qua đánh giá, và đã có những cuộc tranh luận về phong cách mã hóa và lựa chọn thiết kế, nhưng điều đó chỉ cảm thấy ... bình thường .

Nếu các thay đổi mã đang bị chặn trong nhiều ngày ... vài tuần kể từ khi đến QA để thử nghiệm "vì đánh giá", nghiên cứu về các thủ thuật VCS sẽ là cách ít khả năng nhất để giải quyết vấn đề này. Thay vào đó, người ta sẽ tập trung tốt hơn vào nỗ lực tìm hiểu các vấn đề theo cách tổ chức quá trình xem xét.

• <sup>- Oh sự tích hợp của sự thay đổi này đã bị trì hoãn nhiều vì người đánh giá đột nhiên bị ốm, thật là bất hạnh.
  - Xin chào! Hell-lo-oo, bạn đã bao giờ nghĩ đến việc có những người đánh giá dự phòng để giải quyết những trường hợp như thế chưa?</sup>

Vâng. Nhưng chỉ khi bạn nói về kiểm soát nguồn phân tán. Với tập trung - nó phụ thuộc.

Nếu chỉ có vài lập trình viên thì sẽ mất ít thời gian. Chắc chắn ít hơn các bản sửa lỗi sẽ cần thiết để loại bỏ lỗi và nợ kỹ thuật sau này.

Nếu có rất nhiều lập trình viên, bạn có thể ủy thác nhiệm vụ xem xét mã thực tế cho các trung úy và yêu cầu nhà phát triển dẫn đầu thay đổi (gần như) không nghi ngờ gì nữa. Nó hoạt động cho nhân Linux, tôi không nghĩ rằng có bất kỳ dự án phần mềm nào lớn hơn ...

Một lần nữa, nếu dự án nhỏ, khách hàng tiềm năng sẽ nhanh chóng xem ai cung cấp mã tốt và ai tạo mã xấu. Anh ta sẽ nhanh chóng thấy rằng J.Random viết mã tốt, chỉ cần kiểm tra các quyết định kiến ​​trúc trong khi thực tập sinh viết mã xấu cần được xem xét từng dòng trước khi hợp nhất. Phản hồi theo cách này được tạo ra sẽ giảm gánh nặng bảo trì xuống và cung cấp kinh nghiệm trực tiếp về bất cứ điều gì thực tập viên thực sự học và nên được giữ trong công ty. Việc kéo và sáp nhập chi nhánh từ các gitrepo khác chỉ mất khoảng vài chục giây, thông thường việc đọc tiêu đề của thông điệp cam kết sẽ mất nhiều thời gian hơn, vì vậy sau khi tôi biết ai có thể tin tưởng để viết mã tốt, việc hợp nhất mã của người khác là không thành vấn đề.

Đánh giá mã không nhất thiết đòi hỏi sự chú ý của chỉ những lập trình viên giỏi nhất của bạn. IMO, nó nên là một thứ không chính thức. Chỉ cần một ý kiến ​​thứ hai hoặc một cặp mắt thứ hai về một đoạn mã từ một người không phải là tân binh trước khi nó được kiểm tra vào sản xuất. Nó giúp giảm thiểu sự giám sát lớn trong khi cũng giúp mọi người trở nên tốt hơn trong việc viết mã như một nghề thủ công bằng cách tiếp xúc với các quan điểm phát triển khác.

Sắp xếp của một lite lập trình cặp ít đáng ghét. Nói cách khác, nó không mất nhiều thời gian và bạn không cần phải đợi ai đó hàng giờ. Bất cứ điều gì trong quá trình phát triển của bạn liên quan đến việc mọi người chờ đợi mọi thứ là một sự lãng phí tiền bạc và làm tê liệt động lực / tinh thần, IMO.

Nếu đánh giá mã có nghĩa là ngăn chặn 99,5% lỗi trước khi chúng xâm nhập vào cơ sở mã của bạn ngay từ đầu, thì sẽ không có điểm thực sự nào đối với việc kiểm soát phiên bản tinh vi. Điều đó nói rằng, git ban đầu rất đáng sợ nhưng việc sử dụng chung cơ bản không phức tạp và nó có thể cấu hình cao .. Bạn sẽ có thể dừng lại trong vài giờ để dạy mọi người cách sử dụng nó. Mọi người cam kết. Tất cả trừ các tân binh noobiest xem xét cho đến khi họ thể hiện chuyên môn ở một cái gì đó.

Miễn là những thay đổi được gửi đã được xem xét bởi 'lập trình viên giỏi nhất', bất kỳ ai cũng nên được phép gửi mã. Người duy nhất có khả năng thực thi quyền kiểm soát trên kho lưu trữ là Kỹ sư phát hành, nếu người đó tồn tại.

Cá nhân, tôi sẽ rất bực mình nếu tôi phải kiểm tra mã của người khác.

Một số đầu vào về chỉnh sửa của bạn: Không, họ không nên. Đánh giá là một điều ác cần thiết, họ làm nhiều điều tốt hơn hại và lập trình viên giỏi sẽ đánh giá cao điều này. Có thể có sự miễn cưỡng tham gia đánh giá vì họ không thích ý tưởng 'lập trình viên ít hơn' chỉ trích mã của họ. Điều đó thật tệ. Họ sẽ có nhiều khả năng bỏ việc hơn nếu dòng tiền liên tục bị lỗi và thay vào đó họ dành thời gian để dọn dẹp sau khi đệ trình một nửa của người khác.

Vâng, đánh giá là giá trị nó. Tôi không chắc chắn có một cú đánh năng suất nếu quá trình xem xét tỷ lệ thuận với các lý do sau:

• Nó giữ cho các lập trình viên trung thực - nếu bạn biết nó sẽ được xem xét, mọi người sẽ dùng ít phím tắt hơn
• Nó giúp các lập trình viên mới học hỏi từ các lập trình viên nhiều kinh nghiệm hơn
• Nó giúp chuyển giao kiến ​​thức cụ thể của miền
• Đánh giá là một cổng khác, nơi các lỗi và các vấn đề tiềm ẩn có thể được tìm thấy và sửa chữa

Bằng cách không cho phép tất cả các lập trình viên sử dụng kiểm soát nguồn, họ sẽ mất khả năng theo dõi các thay đổi, hoàn tác các lỗi và xem lịch sử thay đổi hợp lý. Tôi không chắc chắn bạn chỉ muốn các lập trình viên "giỏi nhất" của bạn có thể đăng nhập để git.

Phải nói rằng, tôi nghĩ thật hợp lý khi bạn có một người phụ trách một số nhánh quan trọng nhất định, chẳng hạn như một nhánh phát hành. Trong trường hợp này tôi sẽ tưởng tượng rằng mọi người đều có thể sử dụng kho git, nhưng chỉ một số người nhất định hợp nhất vào nhánh phát hành. Tôi không chắc chắn có một cách để thực thi điều này trong git, nhưng nó có thể được thực hiện theo quy trình và chỉ cần kiểm tra không có ai khác đã kiểm tra nó.

Việc sáp nhập vào nhánh phát hành có thể được thực hiện bởi các lập trình viên "tốt nhất" hoặc nhiều khả năng được thực hiện bởi những người có thẩm quyền sau khi đã xem xét đầy đủ.

các lập trình viên giỏi có bỏ việc nếu một phần đáng kể trong công việc của họ là xem lại mã của người khác không?

Nếu họ không thích công việc và buộc phải thực hiện hoạt động này, thì CÓ. Nó rất có khả năng xảy ra. Vì việc tìm kiếm công việc thú vị tiếp theo cho một nhà phát triển giỏi hiện nay không phải là một thách thức lớn.

Các lập trình viên giỏi nhất của bạn có nên kiểm tra mã của người khác để kiểm soát nguồn không?

Hoàn toàn KHÔNG. Đó là chắc chắn lãng phí thời gian của họ, ngoại trừ một số logic quan trọng cần phải ở trạng thái rắn đá .

Tuy nhiên, các nhà phát triển cơ sở hoặc có kinh nghiệm có lẽ nên ở trong thời gian thử việc cho chất lượng mã , để đảm bảo an toàn và đảm bảo rằng mã của họ tuân theo các nguyên tắc phát triển nhóm, ít nhất là trong vài tuần trước khi nhận được đặc quyền.