Là đánh giá mã cần thiết cho các nhà phát triển cơ sở?

Tôi đã làm việc tại hai công ty, mỗi công ty có một phương pháp khác nhau khi đánh giá mã:

Trong công ty đầu tiên, việc đánh giá mã được thực hiện bởi các trưởng nhóm và được yêu cầu sau khi hoàn thành mọi mô-đun.

Tuy nhiên, trong công ty thứ hai, các nhà lãnh đạo nhóm không yêu cầu thực hiện bất kỳ đánh giá mã nào và chỉ kiểm tra các vấn đề về chức năng và thiết kế.

Thế là tôi bối rối. Là quá trình xem xét mã thực sự cần thiết? Nếu là vậy, tại sao? Và nếu không, tại sao không?

Cá nhân tôi nghĩ rằng mọi đoạn mã đều phải trải qua quá trình đánh giá mã, điều đó không quan trọng nếu bạn là nhà phát triển cơ sở hay cấp cao.

Tại sao? Đối với người mới bắt đầu, tiêu đề của bạn không nêu bất cứ điều gì về cách bạn phát triển và nhà phát triển cấp cao có thể học được điều gì đó từ đàn em. Tại công ty của chúng tôi, chúng tôi thay đổi xung quanh để một trong những thành viên khác trong nhóm xem xét mã của bạn ... chủ yếu là chúng tôi được nhóm "đàn em" và cấp cao cùng nhau, vì vậy tất cả những điều không được nói hàng ngày đều có thể được bắt theo dõi Nếu đàn anh không thích mã thiếu niên, anh ta nên lắng nghe lý do tại sao đàn em làm như vậy và nhìn vào nó và xem liệu đó có phải là một giải pháp khả thi có thể được sử dụng trong tương lai không ... đó là vấn đề trở nên khôn ngoan hơn bạn là ai.

Một điều quan trọng về đánh giá mã là không quá hay, nếu bạn là một chàng trai tốt, bạn sẽ chỉ cho phép ngày càng nhiều mã lộn xộn phát triển trong hệ thống. Giống như ngày hôm qua, tôi đã bắt đầu làm lại một ứng dụng hoàn chỉnh mà một nhà phát triển juniordevelop trước đây đã viết, và chúa ơi, mã đó có thể cần được xem xét trước khi anh ta rời đi.

Tôi không hiểu tại sao nên là người chỉ huy nhóm chỉ thực hiện đánh giá nhưng nó yêu cầu một người không ngại chọn "chiến đấu" với một đoạn mã được phát triển kém và đó phải là người quan tâm đến cách mã phải được. Không phải tất cả các công ty đều thuê những người thực sự quan tâm đến những gì họ làm và những quả trứng xấu đó nên IMO không được phép đánh giá mã vì họ có thể chỉ nhún vai và nói "OK" với mã xấu.

Về cơ bản xem xét mã là cần thiết cho tất cả các lập trình viên bất kể kinh nghiệm. Đó là Kiểm soát chất lượng phát triển phần mềm và một trong những lý do Nguồn mở có thể có chất lượng rất cao.

EDIT: Lý do là một người xem xét mã ngày nay có vai trò chính xác như người bảo trì sau này. Nếu mã không có ý nghĩa với anh ta ngày hôm nay, thì nó cũng sẽ không có ý nghĩa sau đó, làm cho lỗi trở nên đắt hơn để sửa chữa. Do đó, MAKE nó có thể hiểu được ngày hôm nay trong khi nhà phát triển vẫn còn nhớ mã. Ngoài ra, người đánh giá có thể thấy các lỗi hoặc thiếu sót mà nhà phát triển đã bỏ qua.

Thật không may, rất ít người muốn làm điều đó, nhưng nhìn từ quan điểm kinh doanh thì nó là bắt buộc.

Tôi làm việc ở một nơi mà việc xem xét mã bây giờ là một yêu cầu nhưng không ít như 3 năm trước. Nó đã tạo ra một sự cải tiến lớn trong mã của chúng tôi và khả năng của những người khác để duy trì mã sau này. Ngay cả các nhà phát triển cấp cao, rất có kinh nghiệm cũng mắc lỗi có thể dễ dàng và lặng lẽ sửa lỗi trong đánh giá mã trước khi QA tìm thấy chúng hoặc tệ hơn trước khi khách hàng tìm thấy chúng. Hơn nữa, ít nhất một người khác ngoài nhà phát triển ban đầu rất quen thuộc với mã.

Thông thường khi một tổ chức thử một cái gì đó mới đối với nó, như chúng ta đã làm với đánh giá mã, có nhiều khả năng chống lại sự thay đổi. Tôi đã thấy hầu như không ai trong số đó (chúng tôi rất vui khi nhận được một bộ phận QA chính thức.) Với việc xem xét mã. Nó khá nhiều chỉ mất một hoặc hai đánh giá để xem giá trị.

Tôi đã tìm thấy các kỹ thuật mới mà tôi đã không cân nhắc cả khi thực hiện đánh giá mã về công việc của người khác hoặc trong việc kiểm tra mã của tôi. Chúng tôi đã tìm thấy các vấn đề về năng lực với các nhân viên mới tương đối nhanh chóng bằng cách xem xét mã và quan trọng hơn là cách họ trả lời đánh giá mã. Chúng tôi đã học được những điều dường như hoàn toàn rõ ràng ngay bây giờ trong phần lập trình dày mà phần đó sẽ không rõ ràng trong bảo trì. Điều này là vô giá. Nó có thể là điều duy nhất cần thiết là một nhận xét về lý do tại sao một cái gì đó đã được thực hiện. Chúng tôi đã tìm thấy một số hiểu lầm cơ bản về thiết kế cơ sở dữ liệu của chúng tôi cần được sửa chữa để báo cáo thực sự có thông tin chính xác.

Thông thường những gì tôi đã thấy trong một bài đánh giá mã là, bằng chính hành động giải thích điều gì đó cho người khác, nhà phát triển sẽ bật một bóng đèn trong đầu và nhận ra rằng có một lỗi mà người đánh giá không nhìn thấy.

Và cậu bé có thể xem xét mã xác định những lập trình viên cao bồi sẽ không tuân theo bất kỳ tiêu chuẩn nào hoặc sử dụng các công cụ được ủy quyền và mã của ai sẽ không bị bắt buộc bởi bất kỳ ai khác. Và nó có thể buộc họ phải tham gia chương trình hoặc ra ngoài.

Những người chống lại việc đánh giá mã thường là những người mà tổ chức cần loại bỏ nhất vì họ biết rằng trong lòng họ, mã của họ không thể vượt qua đánh giá mã.

Anh chàng Agile sẽ nói: "Bạn không cần đánh giá mã, chỉ cần lập trình cặp và viết bài kiểm tra tốt" :)

Đánh giá mã là một cách tốt để truyền bá kiến ​​thức và thực hành tốt thông qua một nhóm. Theo kinh nghiệm của tôi, một ý tưởng tốt là đảm bảo tất cả các mã được xem xét và cố gắng thay đổi người xem lại mã nào.

Trong nhóm hiện tại của tôi, mã của mọi người đều được xem xét như nhau và cả lập trình viên và người đánh giá phải được bão hòa với mã trước khi có thể được phát hành. Điều này chỉ áp dụng cho các nhà phát triển cấp cao đang được xem xét bởi nhiều nhà phát triển cơ sở hơn, nhà phát triển cơ sở đang xem xét người khác hoặc nhà phát triển cấp cao khác đang xem xét lẫn nhau. Nếu người đánh giá thiếu kinh nghiệm hoặc không cảm thấy thoải mái khi xem xét bất kỳ đoạn mã cụ thể nào thì họ sẽ hợp tác với một nhà phát triển khác (và cũng có thể là nhà phát triển ban đầu) để thực hiện đánh giá theo nhóm.

Tôi đã làm việc trong hơn 20 năm, làm việc cho các công ty phần mềm và cho các doanh nghiệp khác nhau và không nơi nào trong số này có quy trình xem xét mã. Tuy nhiên, tôi có thể hiểu và đánh giá cao những lợi ích của việc có một. Về cơ bản, theo tôi hiểu, chúng nên được sử dụng để đảm bảo tuân thủ các tiêu chuẩn, cần tuân thủ để người khác có thể dễ dàng duy trì mã hơn trong tương lai. Khả năng đọc mã cũng có thể được kiểm tra trong quá trình xem xét vì điều này cũng sẽ đảm bảo rằng bảo trì có thể hoạt động hiệu quả với mã.

Hiện tại, tôi làm việc trong một cửa hàng nhỏ nơi tôi là nhà phát triển duy nhất. Thỉnh thoảng chúng tôi đã đưa các nhà thầu để giúp đỡ tồn đọng. Ít nhất một hoặc hai trong số các nhà thầu đó đã viết mã không nhất thiết phải đáp ứng các tiêu chuẩn của tôi hoặc của công ty, nhưng nó đã hoạt động tốt và ít nhất là có thể hiểu được. Khi tôi chỉ ra vấn đề này cho ban quản lý, họ không quan tâm, họ chỉ muốn biết liệu nó có làm những gì chúng tôi trả cho họ không. Vì vậy, tôi đoán nó chỉ phụ thuộc vào công ty, và việc có sạch hay không, dễ duy trì mã là sản phẩm mong muốn hoặc nếu họ chỉ muốn thứ gì đó hoạt động tốt với tiền.

Rõ ràng là một nhà phát triển và là một người phải duy trì mã, tôi muốn làm việc với mã sạch tuân theo một tiêu chuẩn nào đó, nhưng tôi không phải lúc nào cũng có sự xa xỉ đó, vì vậy tôi tận dụng tốt nhất và giải quyết những gì tôi có , ngay cả khi điều đó có nghĩa là đôi khi phải viết lại một số mã theo tiêu chuẩn của riêng tôi.

Đánh giá mã có thể xác định lỗi sớm hơn trong vòng đời phần mềm khi các vấn đề dễ dàng hơn (và rẻ hơn) để khắc phục. Tại SmartBear, chúng tôi đã phát triển một công cụ đánh giá mã ngang hàng và cũng đã thực hiện rất nhiều nghiên cứu về cách làm cho các đánh giá mã hiệu quả. Dựa trên dữ liệu từ khách hàng của chúng tôi, các lỗi được tìm thấy trong đánh giá mã rẻ hơn 8-12 lần để tìm và sửa so với các lỗi được tìm thấy trong QA. Tiết kiệm chi phí một mình làm cho đánh giá mã có giá trị, nhưng có nhiều giá trị hơn thế. Đánh giá mã là một cách tuyệt vời cho mọi người trong nhóm học hỏi và cải thiện như các nhà phát triển phần mềm.

Có một số bẫy có thể khiến đánh giá mã trở nên kém hiệu quả hơn và có vẻ như tổ chức của bạn bị bắt trong một trong số chúng. Làm cho mã xem xét về mã, không phải người. Các tiêu đề có nghĩa là không có gì trong một đánh giá mã. Kháng cáo lên chính quyền (bạn phải làm theo cách của tôi vì tôi là trưởng nhóm) làm hại nhiều hơn là tốt. Dạy thay. Các kỹ sư cao cấp nên giải thích lý do tại sao nó nên được thực hiện theo cách của họ, không chỉ yêu cầu đó là. Nếu bạn gặp khó khăn trong việc giải thích một khái niệm, đó cũng là một kinh nghiệm học tập cho bạn. Cả hai bạn sẽ là nhà phát triển tốt hơn cho những nỗ lực bạn bỏ ra.

Tôi nghĩ rằng mã xem xét TẤT CẢ MÃ là quá mức cần thiết. Lượng thời gian cần thiết để xem xét tất cả các mã có thể được chi tiêu tốt hơn ở nơi khác. Alterntivley Tôi nghĩ rằng mã quan trọng và hoặc các phần đặc biệt phức tạp cần xem lại mã nhưng chắc chắn không phải mọi dòng mã.

Theo tôi, mã sẽ được sử dụng bởi một công ty, cho dù nó được viết bởi nhà phát triển Junior hay Senior, luôn luôn phải được xem xét. Tại sao? Bởi vì nếu mã có một vài lỗi thì sao? Và nếu trong thời gian mã này được sử dụng, chương trình bị lỗi thì sao? Để ngăn chặn những điều này xảy ra, tất cả các mã nên được xem xét trước khi sử dụng.

Nhưng những gì về các công ty không xem xét mã? Có lẽ họ là những công ty có nhiều vấn đề về công nghệ và rất nhiều, như họ nói với người tiêu dùng, "sự cố" ;-).

Vì vậy, hãy để tôi trả lời tất cả các câu hỏi của bạn:

• Có, quá trình xem xét là cần thiết.
• Tại sao? Vì những lý do tôi đã nêu ở trên.

Rà soát mã : Quá trình rà soát mã phải là một vấn đề quan trọng đối với tất cả mọi người, tôi sẽ giải thích tất cả những người nhận được lợi ích do tiến hành đánh giá mã cũng như những lợi ích họ đang nhận được là gì.

1. Lợi ích mà Công ty thu được do tiến hành rà soát mã : Nếu tiến hành đánh giá mã thường xuyên, công ty có thể nhận được các sản phẩm cuối cùng theo cách tối ưu hóa tốt hơn giúp họ có được thương hiệu trên thị trường và cũng giúp công ty nhận hoặc cải thiện mức CMMI hiện tại của họ .

2. Lợi ích cho trưởng nhóm do tiến hành đánh giá mã: Như chúng ta đều biết một giáo viên có thể dễ dàng xác định các lỗi, bởi vì họ đang xem xét các câu trả lời của học sinh thường xuyên hơn, vì vậy họ có thể có ý tưởng, trong đó các lĩnh vực có thể có thể cho những điều sai trái. tương tự, trưởng nhóm cũng biết những điều không ổn trong lĩnh vực này. Làm thế nào chúng ta có thể khắc phục những điều đó. Và cũng giúp Trưởng nhóm nắm bắt các ý tưởng tin tức từ nhà phát triển cơ sở.

3. Lợi ích cho Nhà phát triển cơ sở do tiến hành đánh giá mã: Nhà phát triển Junior có thể dễ dàng nắm bắt các ý tưởng về Quy trình đánh giá mã, ngoài ra họ có thể có được tiêu chuẩn mã hóa, Đối với trường hợp: để tạo API theo cách phù hợp, họ sẽ học tiêu chuẩn hóa mã hóa có thể giúp họ trong tương lai đặc biệt khi họ trở thành bài đăng cấp cao hơn.

Vì vậy, Kết luận của tôi là Đánh giá mã là một Quy trình rất Rất quan trọng đối với tất cả [ngay cả đối với Thành viên nhóm], vì Đánh giá mã giúp chúng tôi sửa lỗi bất cẩn trong mã của mình, vì chúng tôi đều là con người, vì vậy chúng tôi không thể dự đoán rằng chúng tôi không bao giờ làm những lỗi bất cẩn trong mã.

Sự khác biệt với việc can thiệp vào ý tưởng của bạn trước khi kiểm tra mã của bạn (đánh giá) hoặc sau đó là do lỗi, quá thông minh / khó hiểu hoặc không tuân theo các thực tiễn tiêu chuẩn được chấp nhận? Có phải đó là bản ngã của bạn?

Bạn không thể coi thường giá trị của việc xem xét mã hoặc bất cứ điều gì khác chỉ vì nó được triển khai kém bởi một thành viên nhóm kém chất lượng hơn mà bạn không tôn trọng. Đánh giá mã không phải là một quá trình phức tạp cao mà chỉ có một vài siêu lập trình viên có khả năng nắm bắt. Tôi không chắc có nhiều lập trình viên hoặc nhà văn chuyên nghiệp có khả năng hoặc có thời gian để tự chỉnh sửa.

Bạn đã bao giờ quay trở lại một dòng mã vài tháng sau đó và tự hỏi tôi đang nghĩ gì? Sẽ có cơ hội tốt hơn để bắt nó với một đánh giá mã. Bạn vừa bắt được nó và bạn chỉ tốt hơn một chút so với lập trình viên mà bạn đã ở cách đây một thời gian - tôi hy vọng.

IMO một đánh giá mã cần thiết cho tất cả các nhà phát triển, nhưng chỉ khi những người thực hiện đánh giá mới có thẩm quyền. Trước đây, tôi đã bị từ chối mã trong một bài đánh giá bởi vì, tôi không phải là bạn, tôi SOLIDđã làm theo , đã thực hiện một số Dependency Injection và mã được sắp xếp thành các không gian tên và thư mục theo thiết kế logic và bao gồm một bộ thử nghiệm đơn vị nhỏ để xác minh mã. Mã bị từ chối là "quá phức tạp" và tôi được yêu cầu sử dụng một lớp để làm mờ mọi thứ cùng nhau và loại bỏ các bài kiểm tra vì đó không phải là cách công ty viết mã.

Đánh giá mã như thế là vô ích, nhưng đánh giá mã với nhóm có thẩm quyền thường có thể chiếu sáng một cái gì đó về thiết kế (ví dụ: Tại sao bạn nên làm X và Y chứ không phải Z) hoặc chỉ ra một lỗ hổng thực tế (ví dụ: Làm X sẽ khiến Y thất bại vì lý do không chính xác).

Tất nhiên Mã đánh giá là không cần thiết . Sau đó, một lần nữa, không phải là kiểm tra, tích hợp liên tục, kiểm soát nguồn, sự tham gia của khách hàng, định hình, phân tích tĩnh, phần cứng tốt, xây dựng bằng một lần nhấp, theo dõi lỗi, danh sách tiếp tục.

Cùng với Code Reviews, những điều tôi đề cập ở trên là các công cụ giúp đảm bảo chất lượng phần mềm. Với sự kết hợp của kỹ năng, may mắn, thời gian và quyết tâm; bạn có thể cung cấp phần mềm chất lượng mà không cần bất kỳ thứ gì trong số này, nhưng nhiều khả năng là bạn sẽ không .

Trong kịch bản của bạn, không có gì phải nhầm lẫn. Không phải mọi tổ chức thưởng thức trong mọi thực hành tốt nhất. Họ có thể không đồng ý với nó, nó có thể mâu thuẫn với một thực tiễn tốt nhất khác mà họ thực hiện hoặc họ có thể cho rằng chi phí thực hiện nó là quá lớn đối với họ tại thời điểm này. Tùy thuộc vào hoàn cảnh của họ, họ có thể đúng khi làm như vậy, hoặc họ có thể đang tạo ra một nền kinh tế sai lầm. Đối với một số công cụ, (ví dụ: kiểm soát nguồn) tỷ lệ hoàn vốn / nỗ lực rất tốt đến mức sử dụng nó là không có trí tuệ; đối với những người khác, nó không rõ ràng.

Không có nghi ngờ rằng xem xét mã là một thực hành giới thiệu một chi phí đáng kể. Do đó, các tổ chức sẽ tìm cách giảm thiểu chi phí đó, bằng cách không thực hiện hoặc chỉ thực hiện trong một số tình huống (ví dụ: đối với thành viên nhóm thiếu niên hoặc thay đổi đặc biệt là lông). Không phải lúc nào cũng rõ ràng là nó trả lại nhiều tiền hơn (trong việc bắt lỗi, giảm nợ kỹ thuật hoặc chia sẻ kiến ​​thức) so với chi phí. Hầu hết các khoản hoàn vốn đó rất khó để định lượng, trong khi đó rất dễ dàng để đếm số giờ làm việc mà tổ chức của bạn dành để thực hiện đánh giá. Bit dễ nhất để định lượng (giảm số lượng lỗi) là dễ dàng quy cho các yếu tố khác (ví dụ: "tất nhiên nó có ít lỗi hơn, nó trưởng thành hơn").

Chúng tôi làm trò chơi bóng đá trực tuyến ở Thổ Nhĩ Kỳ. Rất nhiều người dùng và bậc thầy trò chơi giúp chúng tôi về chức năng. Ngoài ra họ cho ý kiến ​​về các tính năng cần thiết. Vì vậy, tôi nghĩ rằng, nếu bạn có nhiều người dùng, các bài kiểm tra chức năng có thể được thực hiện để giúp đỡ hoặc nhận huy hiệu. Collobration của các nhà phát triển, bậc thầy trò chơi và người dùng với các diễn đàn, nhóm hỗ trợ và môi trường thử nghiệm riêng tư tạo ra một dự án xã hội.

Chắc chắn đánh giá mã và chia sẻ kinh nghiệm giữa nhóm phát triển là cần thiết nhưng nếu nó không quan trọng, bạn không phải ép buộc bản thân.

Tôi nghĩ rằng việc kiểm tra bên thứ 2 dài bao nhiêu tùy thuộc vào vòng đời của bạn, cho dù bạn nhanh nhẹn hơn hay nhiều thác nước hơn trong quy trình của bạn. Tôi nghĩ thật hợp lý khi thực hiện các thiết kế / kiểm tra cấp cao, cũng như kiểm tra thiết kế cấp chi tiết hơn. Tôi nghĩ cũng tốt khi có sự tham gia của nhiều thành viên trong nhóm để kiểm tra.

Chúng thực sự cần thiết vì chúng có ít kinh nghiệm.