Các lập trình viên Junior có nên tham gia với tư cách là người đánh giá mã trong các dự án của Lập trình viên cao cấp không?

Một trong những thành viên trong nhóm của tôi, một lập trình viên cơ sở, có kỹ năng lập trình ấn tượng cho mức độ kinh nghiệm của anh ấy.

Và trong quá trình đánh giá mã, tôi tin vào việc nhấn mạnh vào việc học, không chỉ ra sai lầm.

Nhưng các lập trình viên cơ sở có nên tham gia vào việc đánh giá mã cho các lập trình viên cao cấp hơn không? Hoặc các đánh giá mã chỉ nên được tham gia bởi các lập trình viên có kinh nghiệm tương ứng?

Mục đích chính của đánh giá mã là tìm ra lỗi hoặc các vấn đề tiềm ẩn. Những người tham gia được yêu cầu trong đánh giá phải là những người phù hợp nhất để xác định những vấn đề này, bất kể chức danh hay thâm niên của họ.

Ví dụ, nếu một ứng dụng đang được phát triển bằng Python và kỹ sư cơ sở có nhiều kinh nghiệm với ngôn ngữ Python hơn kỹ sư cao cấp đã viết mã, thì chúng có thể là một tài sản quý giá trong việc chỉ ra các phương pháp khác để làm một cái gì đó, nhưng chúng cũng có thể có ít kiến ​​thức về hệ thống nói chung.

Ngoài kinh nghiệm về các công cụ và công nghệ, cũng xem xét kinh nghiệm trong lĩnh vực ứng dụng. Một người có 20 năm kinh nghiệm nhưng chỉ có 1 hoặc 2 trong ngành tài chính có thể được giúp đỡ bằng cách có một nhà phát triển ít kinh nghiệm hơn chỉ với 5 năm kinh nghiệm trong ngành tài chính xem xét công việc của mình.

Mời các nhân viên ít kinh nghiệm quan sát và tham gia càng nhiều càng tốt, quy trình xem xét mã cũng có thể có lợi để cho phép họ tìm hiểu cơ sở mã, đặt câu hỏi và tìm hiểu về những gì được mong đợi ở họ trong không chỉ các đánh giá mã, mà trong mã mà họ sản xuất. Tuy nhiên, có lẽ bạn không muốn có quá nhiều người tham gia (thay vào đó tập trung vào những người có thể hỗ trợ đầy đủ việc xem xét mã và mục đích của nó) trong quy trình.

Điều này thực sự áp dụng cho bất kỳ loại đánh giá nào - yêu cầu, thiết kế, mã ...

Các lập trình viên cơ sở có nên tham gia với tư cách là người đánh giá mã trong các dự án của các lập trình viên cao cấp?

Vâng, họ nên. Đó là một kinh nghiệm học tập tốt để đọc mã của người khác. (Và điều đó áp dụng cả cho mã tốt và xấu. Mặc dù người ta sẽ hy vọng rằng mã của nhà phát triển cấp cao sẽ không tệ ...)

Rõ ràng, thật không khôn ngoan khi chỉ có đàn em làm bài đánh giá mã. Và không khôn ngoan khi đặt kỳ vọng quá cao vào đàn em về những gì họ có thể tìm thấy. Tuy nhiên, bạn cũng có thể ngạc nhiên bởi những hiểu biết mới mẻ mà các lập trình viên cơ sở có thể mang đến cho bàn.

Một câu trả lời khác đề cập đến đàn em đang / cảm thấy sợ hãi. Đó không phải là việc xem xét mã nào về ... cho người được đánh giá hoặc người đánh giá. Nếu điều đó đang xảy ra, nhóm của bạn cần thay đổi cách thức đánh giá mã của nó ... và có lẽ các mối đe dọa cần phải được kéo vào hàng.

Tôi sẽ nói thêm rằng nếu một lập trình viên "Thiếu niên" không thể hiểu được mã người cao niên thì bản thân nó là một thước đo tốt về mã. Có thể đôi khi không thể viết mã mà mọi người đều có thể hiểu được, nhưng hy vọng đó là những ngoại lệ - nếu chỉ có 1 hoặc 2 người có thể hiểu mã thì điều gì xảy ra khi những người đó không có sẵn và có vấn đề với nó không

Cung cấp cho mọi người những thách thức mới giúp họ phát triển; cũng có thể là không phải ai cũng bị loại ra để xem xét mã nhưng có vẻ giáo điều khi khẳng định ai đó có một tiêu đề (được xác định bởi chính trị và trò chơi nhân sự ) trước khi họ đủ điều kiện để xem xét.

Như những người khác đã chỉ ra một đánh giá mã có thể là một quá trình hai chiều; Nó giúp mọi người hiểu cơ sở mã, vì vậy chia sẻ kiến ​​thức, nó giúp đàn em học hỏi những cách thức và kỹ thuật mới và tốt hơn từ người cao niên của họ và nó giúp người cao niên tinh chỉnh hiểu biết của họ và bằng cách viết để đảm bảo mọi người có thể theo dõi mã bạn có nhiều mắt hơn bắt lỗi.

Mục đích của đánh giá mã là để nắm bắt các vấn đề mà việc kiểm tra không thể nắm bắt được, như các vấn đề về khả năng bảo trì và các trường hợp góc. Tôi sẽ lập luận rằng theo nhiều cách, các lập trình viên cơ sở phù hợp hơn với mục đích đó:

• Họ có nhiều thời gian hơn nói chung.
• Họ có nhiều khả năng đưa nó từ từ, từng dòng một, không cần thiết phải hiểu mã.
• Khi bạn nói về mã được duy trì, điều đó có nghĩa là bởi mọi người trong công ty, không chỉ các lập trình viên hàng đầu của bạn. Điều đó có nghĩa là các lập trình viên cơ sở của bạn phải có khả năng hiểu mã để khai báo nó có thể duy trì được.
• Họ thường ít có khả năng đưa ra các giả định xấu, tin tưởng rằng một cái gì đó hoạt động theo cách họ cho rằng nó sẽ hoạt động.
• Giáo dục của họ trong một ngôn ngữ lập trình là gần đây hơn, và ít có khả năng bị nhầm lẫn với nhiều năm kinh nghiệm trong ngôn ngữ khác. Ví dụ, một người cao cấp có thể vô tình sử dụng một thói quen anh ta nhặt được từ C ++ để biên dịch nhưng hoạt động khác biệt một cách tinh tế trong Java. Người mới bắt đầu nhận những loại lỗi dễ dàng hơn.
• Người đánh giá mã chỉ cần xác định vấn đề, không nhất thiết phải đề xuất một giải pháp tốt hơn. Họ sẽ thường đưa ra những bình luận dọc theo dòng chữ: "Tôi thực sự không thể tìm ra cách làm nó tốt hơn, nhưng phần này thực sự khó hiểu vì tất cả sự lặp lại." Một lập trình viên có kinh nghiệm hơn sau đó có thể dễ dàng thực hiện các cải tiến mặc dù lúc đầu họ có thể không nhận thấy vấn đề.

Điều đó không có nghĩa là không có cách nào khác để các lập trình viên cao cấp phù hợp hơn để thực hiện đánh giá, nhưng quan điểm của tôi là bạn đang làm một việc không hài lòng nếu bạn không tận dụng tối đa sự đa dạng của nhóm của mình.

Người cao niên thường sẽ được yêu cầu duy trì mã, điều quan trọng là họ có thể hiểu nó.

Đôi khi đàn em là những người duy nhất có sẵn để xem xét mã của các nhà phát triển cao cấp. Mã có nên chờ để đi đến QA (chúng tôi không đẩy bất kỳ thứ gì ra khỏi nhà phát triển mà không xem xét mã và tôi cũng giả sử loại đánh giá mã này) vì sếp của cấp cao đang trong kỳ nghỉ?

Tôi cũng đặc biệt yêu cầu đàn em viết mã đánh giá một cái gì đó khi tôi biết rằng họ sẽ làm điều gì đó tương tự cho một khách hàng khác hoặc nếu tôi biết họ đã làm việc với một thứ khác tương tự hoặc họ có một bộ kỹ năng cụ thể.

Nếu mã khá đơn giản, tôi thường nhờ một người đàn em thực hiện đánh giá. Tại sao phải lãng phí thời gian của người cao niên nếu người thiếu niên hoàn toàn có khả năng thực hiện công việc? Nếu đàn em cảm thấy sợ hãi bằng cách xem xét mã của cấp cao, hãy để họ xem xét các phần dễ dàng hơn ban đầu. Sau tất cả, bạn không thể vượt qua được là đàn em cho đến khi bạn ngừng cảm thấy sợ hãi.

Tôi thường thấy rằng nếu tôi phải giải thích mã cho một người thiếu niên không hiểu nó, tôi sẽ thấy một lỗi tôi mắc phải (thường là trong một giả định) và sẽ không có người đánh giá mã có kinh nghiệm nào bắt gặp vì mã không chạy nhưng không làm chính xác những gì đã dự định. Vì vậy, chỉ cần hành động giải thích mọi thứ thường sẽ giúp nhà phát triển thấy một vấn đề mà không có người xem xét mã tìm thấy nó. Vì những người có kinh nghiệm hơn thường không được thực hiện qua mã từng bước, những loại điều này được tìm thấy dễ dàng hơn khi một thiếu niên thực hiện đánh giá.

Tôi thấy rằng có cơ sở tham gia vào đánh giá có một số hiệu ứng tốt. Đầu tiên, nó làm cho họ tự tin hơn khi họ có thể hiểu mã của một người cao cấp. Nó làm cho họ tự tin hơn nữa khi họ có thể tìm thấy một lỗi trong mã đó.

Nó cho họ thấy những quá trình suy nghĩ bên ngoài của chính họ và cho phép họ thấy những cách xử lý khác. Ngay cả với tư cách là một người cao cấp, điều này đã xảy ra với tôi - nhìn thấy một cách giải quyết vấn đề khác có thể là một điểm sáng cho những khả năng mới.

Nó giúp họ học cách đọc mã của người khác và điều đó cho họ cơ hội hỏi mã đang làm gì trong khi nó vẫn còn mới mẻ trong tâm trí của tác giả. Điều đó tốt hơn nhiều so với việc phải duy trì điều đó sáu tháng sau khi tác giả đã qua lâu hoặc bận rộn với dự án khác và không có thời gian cho câu hỏi.

Điều đó tốt cho người cao niên vì các câu hỏi đều phơi bày những lĩnh vực tiềm năng nơi thiếu niên yếu và cần tư vấn (để họ có thể chịu trách nhiệm nhiều hơn và cho người cao niên nhiều thời gian hơn để thực hiện các loại nhiệm vụ khác) hoặc các lĩnh vực mà mã đơn giản là không rõ ràng bất cứ ai ngoại trừ tác giả (có nghĩa là nó có thể thậm chí không rõ ràng với tác giả một năm kể từ bây giờ khi nó cần được thay đổi). Nó cũng giúp người cao niên nhận ra rằng đàn em có thể thông minh hơn họ đã cho họ tín dụng. Nó giúp giữ cho tất cả mọi người trên một nền tảng chuyên nghiệp. Xét cho cùng, nếu bạn loại trừ đàn em thì bạn rõ ràng ngụ ý rằng bạn không nghĩ rằng họ có khả năng hiểu được mã không may về mặt tâm lý.

Người cao niên xem xét mã người cao niên có thể tạo ra sự tôn trọng chuyên nghiệp hơn trong tổ chức của bạn. Người cao niên có thể nhận ra rằng họ đã đánh giá thấp đàn em và đàn em có thể nhận ra rằng người cao niên biết nhiều hơn họ đã cho họ tín dụng. Người cao niên đôi khi nghĩ rằng họ có những kỹ năng lớn hơn họ có. Tiếp xúc với mã họ không thể viết là tốt cho những người này vì họ bắt đầu nhận ra họ có nhiều thứ để học hơn. Nó cũng sẽ thúc đẩy những người giỏi nhất để có được các kỹ năng. Ở trường đôi khi các sinh viên B không hiểu tại sao họ không đạt điểm A cho đến khi ai đó chỉ cho họ một mẫu về mức độ A của công việc. Tương tự với đàn em đến người cao niên trong việc xem xét mã.

Câu trả lời của tôi là: Đôi khi . Nó sẽ thay đổi từ lập trình viên sang lập trình viên, và từ nhiệm vụ này sang nhiệm vụ khác.

Dành cho:

• Nếu bạn muốn những người đàn em đó học cách làm một bài đánh giá mã hiệu quả, thì cách tốt nhất là cho họ xem những người cao niên làm điều đó như thế nào.
• Một lập trình viên cơ sở có thể có nhiều kinh nghiệm hơn một người cao cấp trong một ngôn ngữ / miền / cụ thể.
• Bằng cách buộc đàn em đánh giá mã của người cao niên, chắc chắn họ sẽ học được nhiều thứ. Lập trình cặp sẽ là một cách hiệu quả hơn để làm điều này mặc dù, vì bất kỳ câu hỏi mà học sinh có thể có câu trả lời ngay lập tức.
• Không ai là mã là thiêng liêng và không ai tốt đến mức mã của họ không nên được xem xét. Nếu bạn không làm điều này, ai sẽ xem xét mã của những người hàng đầu của bạn?
• Không phải tất cả đàn em đều bình đẳng, và không phải tất cả các đàn anh đều bình đẳng. Đôi khi có thể không có nhiều khoảng cách, vì vậy đừng bị treo trên các chức danh công việc.

Chống lại:

• Có nguy cơ các đánh giá bị sa lầy với các vấn đề không từ các đàn em.
• Mức độ kiến ​​thức / kỹ năng cần thiết có thể đơn giản là vượt quá khả năng của thiếu niên. Điều này sẽ không chỉ lãng phí thời gian của họ, mà còn có thể làm mất tinh thần họ.

Tôi là một người tin tưởng mạnh mẽ rằng mọi người trong nhóm nên tham gia vào cả hai mặt của các đánh giá mã. Người cao niên nên xem lại mã Cao cấp và ngược lại. Tại sao cả hai? Bởi vì thông thường không chỉ là về việc mã có "giải quyết được vấn đề" hay không. Tôi không thể nói cho bạn biết bao nhiêu lần tôi phải giải thích một đoạn mã cho ai đó và đột nhiên nghĩ ra cách làm tốt hơn nhiều vào cuối lời giải thích. Mã đánh giá phục vụ có thể 3 mục đích:

1. Đảm bảo mã là chính xác
2. Khiến người viết suy nghĩ về cách người khác sẽ thấy mã của họ
3. Nhận phản hồi của độc giả về những gì có thể được cải thiện và một đôi mắt chung thứ hai

Tôi là một thiếu niên và tôi thường xem lại mã viết cao cấp. Đó là một chính sách chung của công ty "mọi thứ đều được mã xem xét bởi ai đó". Tôi học được rất nhiều từ việc xem xét mã của họ và có cơ hội để đặt câu hỏi về lý do tại sao mọi thứ được thực hiện theo một cách nhất định. Và đôi khi, tôi đề xuất một cách sạch hơn để làm một đoạn mã nhất định và như vậy. Hiếm hơn nhiều so với những người nói với tôi cách cải thiện mã của mình, nhưng nó đã xảy ra ít nhất một lần.

Nó cũng quan trọng như thế nào chính thức đánh giá mã của bạn. Chúng tôi rất thân mật và bao gồm "hey bạn sẽ xem mã của tôi" được nói trên các hình khối hoặc trong một kênh IRC riêng. Tôi có thể tưởng tượng nếu bạn xem lại mã trong một thiết lập trang trọng hơn, thì thiếu niên có lẽ sẽ sợ hãi hơn nhiều khi xem xét mã của cấp cao.

Tuyệt đối, các kỹ sư cơ sở nên xem lại mã của các kỹ sư cao cấp, ít nhất là đôi khi.

Theo kinh nghiệm của tôi, thật hiếm khi người đánh giá trong bài đánh giá mã một đối một thực sự thấy một lỗi mà người viết mã gốc bỏ qua, cho dù người đánh giá là cấp cao hay cấp dưới; người đánh giá thậm chí không phải là con người . Mặt khác, điều rất phổ biến là người viết mã gốc nhận ra một lỗi trong khi cố gắng giải thích mã, và người đánh giá càng trẻ, điều này càng có khả năng, vì độ sâu cần thiết của lời giải thích.

Theo tôi, một số lợi ích thường bị bỏ qua khi xem xét mã, có thể quan trọng hơn về lâu dài so với việc bắt lỗi:

• Chia sẻ kiến ​​thức về những gì thực sự diễn ra trong cơ sở mã - "Đợi đã, tôi nghĩ Bill có một lớp học X, chúng ta không cần phải viết một cái mới."
• Chia sẻ kiến ​​thức về kỹ thuật tốt và phong cách lập trình.

Trong cả hai khía cạnh này, một nhà phê bình cơ sở có xu hướng được hưởng lợi nhiều hơn một người cao cấp.

Các lập trình viên trẻ hoàn toàn nên thực hiện đánh giá mã cho các đồng nghiệp cao cấp của họ!

Tuy nhiên, họ không nên là người đánh giá duy nhất . Ghép nối chúng với một nhà phát triển có kinh nghiệm hơn cho mỗi đánh giá mã.

Có vô số lợi ích:

• Tác giả sẽ bị buộc phải giải thích thêm về mã của họ. Nói qua mã của bạn là một trong những cách tốt nhất để tìm ra vấn đề với nó, hoặc cách tốt hơn để làm điều đó.

• Tác giả sẽ tìm thấy điểm yếu trong mã của họ. Các dev cơ sở có nhiều khả năng bị nhầm lẫn bởi một số chunk cao cấp hơn. Thông thường, đây là "quá khó khăn" cho lợi ích riêng của họ, và có thể được hưởng lợi từ việc đơn giản hóa.

• Các dev cơ sở sẽ tìm hiểu thực hành mã hóa tốt hơn. Đánh giá mã là một cơ hội để dạy bằng ví dụ.

• Các dev cơ sở sẽ là một người đánh giá mã hiệu quả hơn. Xem lại mã là khó . Mọi người càng có nhiều kinh nghiệm với các đánh giá mã, các đánh giá mã càng nhanh và hiệu quả hơn.

• Các dev cơ sở sẽ có kiến ​​thức sâu hơn về cơ sở mã. Hãy ích kỷ! Bằng cách kéo các dev dev về sớm, bạn sẽ có thể đưa nó cho họ sớm hơn.

• Các dev cơ sở sẽ cảm thấy tham gia nhiều hơn. Các nhà phát triển cơ sở sẽ bắt đầu thấy mã "cao cấp" (và các đồng nghiệp của họ) là ít nước ngoài và đáng sợ hơn. Đây là một lợi ích to lớn và thường bị bỏ qua của các đánh giá mã.

• Các dev cơ sở là một đôi mắt mới. Họ không được truyền bá như một người đã làm việc trên cơ sở mã trong một thời gian dài. Các dev cơ sở có nhiều khả năng chỉ ra những cách khác nhau để hoàn thành mọi thứ khi họ đặt câu hỏi. Đừng nhún vai những bình luận hoang dã của họ mà không cần phải xem xét ít nhất!

• Các nhà phát triển cao cấp phải chịu trách nhiệm. Tôi thường thấy các tình huống trong đó các nhà phát triển cấp cao có xu hướng phủ bóng lên mã của nhau (tin tưởng, lười biếng, v.v.). Một đôi mắt thêm giúp ngăn cản nó.

Nhược điểm cần xem xét là tất cả các bên liên quan sẽ dành một lượng thời gian hợp lý để thực hiện đánh giá mã. Vì vậy, nó có thể là một chút khó khăn để bán cho quản lý. Tuy nhiên, lợi ích hoàn toàn vượt xa tốc độ chậm hơn.

Một đánh giá mã được thực hiện để xem xét mã, không phải để học. Nếu tôi là một lập trình viên cơ sở, tôi sẽ bị đe dọa để xem lại mã của cấp cao.

Mặt khác, đọc mã của cấp cao là một cách học tuyệt vời, miễn là Người cao cấp có sẵn để trả lời tất cả các câu hỏi.

Hai lựa chọn thay thế có thể là:

• hãy để Junenson tham dự các cuộc họp xem xét mã và để mọi người tham dự được mở cho một số cuộc thảo luận về việc dạy / học
• thực hành lập trình cặp