Các quy trình xem xét mã phổ biến là gì và những gì được coi là xấu?


16

Công ty của tôi gần đây đã bắt đầu thực hiện đánh giá mã chính thức. Quá trình diễn ra như sau: bạn gửi vào một github, yêu cầu yêu cầu kéo, mã được khoảng ba người xem xét, sau đó nếu tất cả vượt qua, mã của bạn sẽ được gửi vào.

Quá trình này có vẻ công bằng, tuy nhiên ba người thực hiện đánh giá mã dường như không công bằng. Tôi nhận thấy rằng khi tôi đặt mã của mình để xem xét, tôi nhận được bất cứ nơi nào trong khoảng 100-200 bình luận. Con số hàng đầu đối với tôi là 300 bình luận một lần. Tất nhiên, bạn nghĩ rằng đó là những thay đổi lớn, nhưng đây có thể là những thay đổi rất nhỏ cũng với ít hơn 50 dòng mã (bao gồm các bài kiểm tra đơn vị). Tất cả các ý kiến ​​được coi là "phải làm" và không có tranh luận.

Với ý nghĩ đó, vấn đề chính của tôi ở đây là có vẻ hơi quá đáng. Tôi đã nói chuyện với nhóm và họ nói với tôi về cơ bản rằng chỉ vì tôi đã có quá nhiều năm phát triển trong php không có nghĩa là tôi là một "nhà phát triển". Tất nhiên điều này có vẻ đau đớn hơn không. Ngoài ra tôi nhận thấy rằng trong nhóm, họ dường như không tạo ra nhiều bình luận và hầu hết thời gian họ bỏ qua hoặc bỏ qua các bình luận hoặc đề xuất khác hiếm khi chấp nhận nó như một điểm hợp lệ ngay cả khi có gì đó bị phá vỡ.

Vì vậy, câu hỏi của tôi là nếu điều này là công bằng? Hay phổ biến?


3
Những loại bình luận bạn đang nhận được? Có vẻ như rất nhiều. Là định dạng bình luận? Mã hóa? Thật khó để trả lời mà không biết thêm về bản chất của các bình luận (và có thể chính xác những gì trong mã của bạn đã kích hoạt các bình luận).
MetalMikester

1
Xin chào - không chắc đó có phải là thuật ngữ đúng hay không, nhưng chủ yếu là các nhận xét "thực tiễn tốt nhất" chung chung như đổi tên biến, chức năng di chuyển, đổi tên chức năng lên tới 3-5 lần, v.v. Chúng tôi đã cài đặt phpc để định dạng chính xác.
dùng1207047

Cũng quên đề cập đến trên vé này, tôi thực sự là một nhà phát triển cấp 3 tại công ty này. Tôi có chứng chỉ php và đã hoạt động rất tốt trong 8 năm qua khi được tuyển dụng tại đây. Điều này chỉ mới gần đây mà điều này bắt đầu xảy ra. Vì vậy, ý tôi là người ta muốn nghĩ rằng sau 8 năm, bạn sẽ biết điều gì đó phải không?
dùng1207047

1
"Vì vậy, ý tôi là người ta muốn nghĩ rằng sau 8 năm, bạn sẽ biết điều gì đó phải không?" - Chà, đôi khi bạn sẽ ngạc nhiên ... Những điều tôi thấy trong công việc ...
MetalMikester

Câu trả lời:


15

Tất cả các ý kiến ​​được coi là "phải làm" và không có tranh luận.

IMHO là vấn đề thực sự, vì không có sự ưu tiên nào trong đó. Khi bạn nhận được 100-300 bình luận, phải có một số người trong số họ có mức độ ưu tiên A (lỗi thực sự), một số trong số họ là B (có khả năng dẫn đến lỗi sau này) và một số trong số họ là C (mọi thứ khác). Nói với đồng nghiệp của bạn rằng bạn sẵn sàng tôn trọng tất cả các mong muốn của họ, nhưng để thay đổi có hiệu quả và thời gian của bạn bị hạn chế, hãy nhấn mạnh vào một ưu tiên. Sau đó, hãy bắt đầu với việc sửa lỗi A trước, và nếu bạn thực sự có nhiều thời gian hơn sau đó, bạn có thể bắt đầu với B (nếu bạn may mắn, sếp của bạn sẽ hiểu rằng việc sửa lỗi B và C không quá quan trọng, và cung cấp cho bạn một số nhiệm vụ quan trọng hơn thay vì lãng phí thời gian của bạn).


Tôi đã cố gắng nhiều lần để yêu cầu ưu tiên cho ý kiến. Tôi nhận lại một cái gì đó như "tốt đẹp để có" và "bắt buộc." Hóa ra phần lớn trong số họ là "bắt buộc".
dùng1207047

2
Tôi đã thấy điều đó xảy ra khi một nhà phát triển cụ thể được cung cấp nhiều mục hành động từ các đánh giá của họ để ngăn họ làm rối mã trong các khu vực khác của chương trình. Nhưng điều đó sẽ dành cho một nhà phát triển đặc biệt nghèo, người bị "ép buộc" vào dự án và người dẫn đầu không thể loại bỏ họ vì các quyết định quản lý.
Dunk

2
Bạn biết @Dunk, tôi nghĩ bạn đang ở đây. Nhận xét của bạn thực sự gây ấn tượng và tôi đã chấp nhận câu trả lời này vì tôi không nghĩ mình có thể chấp nhận bình luận. Tôi là "người ngoài cuộc" trong nhóm này và nhận ra tại sao vòng tròn bên trong đang nhận được những đánh giá tốt hơn và nhanh hơn và những người bên ngoài thì không. Tôi đã bị "ép buộc" vào đội ngũ này bởi ban quản lý, vâng và chúng tôi "buộc" phải làm việc cùng nhau. Vì vậy, điều này nghe có vẻ rất hợp lý và một lời giải thích hợp lý về lý do tại sao nó khắc nghiệt hơn. Điều đó hoặc tôi thực sự bốc mùi ở tiền mã hóa. Cách duy nhất để tìm ra điều đó là đến một nhóm / công ty khác và tự mình xem.
dùng1207047

4
@ user1207047: Bạn không nên chấp nhận câu trả lời vì bạn thích một trong những bình luận bên dưới vì nó đi ngược lại các tiêu chuẩn và mục đích của trang web (Tôi nghĩ rằng tôi đang cảm nhận một mô hình ở đây). Có chức năng bình luận upvote cho điều đó.
webbiedave

10

Đánh giá mã có thể là một quá trình gây chia rẽ.

Bạn đang ở một ngã ba quan trọng, mặc dù. Làm một phân tích chu đáo về đánh giá của họ. Có phải họ đang xác định các vấn đề chọn nit, hoặc làm nổi bật các lỗ hổng nghiêm trọng trong phong cách và logic của bạn?

Nếu đó là trước đây, tôi khuyên bạn nên làm việc theo hướng giải quyết (công việc mới hoặc quy trình xem xét mã mới).

Nếu đó là sau này, tôi khuyên bạn nên đọc và nghiên cứu nhiều mã để cố gắng đưa mã của bạn đạt chất lượng chuyên nghiệp.


Này, ý nghĩ tốt. Từ những gì tôi có thể thu thập một số trong số chúng thực sự là phân tích chu đáo nhưng hầu hết trong số chúng xuất hiện chọn nit như chức năng di chuyển hoặc đổi tên chức năng. Vấn đề là khi họ giải thích quá trình suy nghĩ của họ thì điều đó thực sự có ý nghĩa nhưng trong số họ, họ không làm điều tương tự và mắc lỗi giống như tôi.
dùng1207047

Thậm chí nhiều hơn, đánh giá mã sâu đến mức tôi quên mất những gì tôi đã làm và tạo ra nhiều lỗi hơn khi sửa ứng dụng do quá nhiều bình luận. Ví dụ, một lần tôi được yêu cầu viết lại một phần lớn mã. Trước đó, mã là chính xác và chức năng. Sau khi mã đánh giá và gần 150 bình luận, chức năng ban đầu và tính chính xác đã biến mất và hàng tấn lỗi đã được chèn vào. Khi tôi nhận ra điều này và sửa chúng, về cơ bản tôi đã nói: "Vâng, quy trình xem xét mã của chúng tôi giúp bạn trở thành một lập trình viên tuyệt vời bởi vì bây giờ bạn sẽ quay lại sửa nó và việc đó dễ dàng hơn."
dùng1207047

8
@user: việc đặt tên cho các phương thức / hàm rất quan trọng, nó không nhất thiết phải chọn nit. Nếu bạn làm một công việc kém với việc đặt tên thì điều đó có thể gây khó chịu cho nhóm của bạn. Nếu bạn không thể đưa ra một cái tên rõ ràng thì có lẽ đó không phải là một chức năng tốt. Bạn dường như là anh chàng "mới" và những người khác dường như có một phương pháp cho sự điên rồ của họ mà có lẽ họ đã thảo luận nhiều lần trước đây. Như vậy, lý do cho ít bình luận. Tôi đề nghị bạn tìm hiểu những gì họ muốn và cố gắng tuân thủ chứ không phải đầu mông. Kiếm được một số sự tôn trọng, sau đó bạn sẽ ở trong một vị trí để đưa ra những ý tưởng thay thế sẽ được đáp ứng với một tâm trí cởi mở.
Dunk

1
@user: Có vẻ như bạn đang cần tiêu chuẩn mã hóa / thiết kế.
Dunk

2
@user: Tất cả những gì bạn có thể làm là cố gắng làm việc trong hệ thống và chứng minh bạn là một người chơi nhóm. Nếu bạn đã làm điều đó. sau đó hoặc nhận thức của bạn là không chính xác, bạn đang đối phó với những người không hợp lý, họ nhận thấy thái độ của bạn là gây tranh cãi HOẶC đó chỉ là chính trị công sở khó chịu. Những người duy nhất bạn có quyền kiểm soát là thái độ / nhận thức của bạn. Nếu bạn bị thuyết phục rằng bạn không phải lúc nào đó xúi giục vấn đề thì tôi không biết tại sao bạn lại ở lại. Đi tìm nơi nào đó thú vị để làm việc vì mọi người hòa đồng. Nếu những vấn đề tương tự xảy ra ở nơi khác thì hãy nhìn vào gương.
Dunk

5

Dường như bởi ý kiến ​​của bạn rằng các đồng nghiệp của bạn đang sử dụng quy trình xem xét mã để đồng ý một phương pháp hoặc đánh bóng mã. Tôi mới bắt đầu thực hiện đánh giá mã như bạn và tôi nhận thấy rằng đôi khi chúng ta thảo luận rất nhiều về những điều chỉ là phương pháp tiếp cận hoặc cải tiến. Điều này không tệ chút nào về mức độ hợp lý của nó (300 bình luận có vẻ quá nhiều đối với tôi, nó phải trông giống như một chủ đề reddit)

Có thể bạn cần phải đồng ý một số quyết định kiến ​​trúc về mã trước khi bắt đầu triển khai nó hoặc có thể chỉ đồng ý về việc đặt tên cho các quy ước, mẫu và thực hành tốt để tất cả các bạn đều biết nó được coi là "mã tốt".

Nếu bạn đang tuân thủ các tiêu chuẩn mã của bạn như bạn nói và mã hoạt động như dự định, thì không nên có quá nhiều bình luận, vì vậy họ đang sử dụng mã của bạn như một diễn đàn hoặc họ đang troll bạn vì dường như bạn đang chỉ.

Tôi sẽ cố gắng tự phê bình, cố gắng tham gia vào các cuộc trò chuyện và xem lý do của tất cả các bình luận này và có thể nói với họ về nó theo cách xây dựng để xem tại sao họ không hài lòng với mã của bạn và nếu bạn có thể mã theo cách làm cho mọi người hài lòng và công việc không bị kẹt trong đánh giá mã.

Tôi chỉ đọc những bình luận cuối cùng của bạn, đôi khi bạn không đồng ý với mã bạn có thể xem qua nó hàng trăm lần và đề xuất những thay đổi ở mọi nơi không làm bạn hài lòng vì lý do thực sự là bạn sẽ đưa ra quyết định kiến ​​trúc khác và bạn không thích mã đó, bất kể bạn tái cấu trúc mã đó bao nhiêu lần. Như tôi đã nói ở trên, có thể bạn cần phải đồng ý cách tiếp cận mã trước đó để khi bạn viết nó, bạn biết họ mong đợi gì từ nó và do đó mã của bạn sẽ hợp lý hơn với họ.


1
100% đồng ý với đoạn cuối: Bạn nên thảo luận về thiết kế dự định của bạn trước khi thực hiện. Ít nhất sau đó bạn đang bắt đầu với một khuôn khổ được cho là chấp nhận được. Sau đó, sau khi thực hiện, có thể có giá trị khác khi thảo luận về thiết kế cuối cùng (không phải mã). Sau đó sửa đổi mã để phù hợp với kết quả của cuộc thảo luận thiết kế cuối cùng. Nếu sau một vài lần thử điều đó và nó không cải thiện được vấn đề thì điều đó sẽ rõ ràng rằng vị trí đó chỉ là một sự phù hợp xấu và bạn nên bắt đầu tìm kiếm ở nơi khác.
Dunk

4

Từ những gì bạn đang nói, dường như với tôi rằng họ có thể có thành kiến ​​với các nhà phát triển php, và do đó họ đang cố gắng tìm mọi điều sai với mã của bạn để chứng minh quan điểm của họ .¹

Về bản thân mã đánh giá, tôi tin như bạn đã nói, rằng một lượng lớn bình luận nhỏ như vậy ít hữu ích hơn một vài lời chỉ trích tốt và hợp lệ. Và mặc dù tôi có kinh nghiệm hạn chế liên quan đến đánh giá mã, nhưng kỹ thuật sau đây đã hoạt động tốt cho các nhóm tôi đã làm việc trong quá khứ.

  • Trước hết, nên sử dụng máy phân tích mã tĩnh để xác định hầu hết các vấn đề trước khi tiến hành đánh giá mã. Ví dụ: chạy mã của bạn thông qua Sonar, Lint hoặc bất kỳ trình phân tích mã tốt nào khác sẽ giúp bạn thoát khỏi hầu hết các vấn đề nhỏ. Đặc biệt là vì người đánh giá của bạn có thể xác định hồ sơ tùy chỉnh để đảm bảo mọi thứ từ đặt khung, khoảng trắng, nhận xét, đặt tên biến phù hợp và nhiều hơn nữa ...
  • Thứ hai, tôi dường như làm việc tốt nếu bạn chia các ý kiến ​​thành các loại khác nhau. Ví dụ, hai danh mục trong đó một nhóm bao gồm những điều nhỏ mà bạn nên lưu ý và áp dụng trong tương lai. Và một nhóm thứ hai cho những bình luận yêu cầu sửa đổi ngay lập tức mã của bạn, điều này sẽ yêu cầu một cam kết khác và đánh giá tiếp theo. Tất nhiên, số lượng ý kiến ​​trong nhóm sau nên nhỏ hơn.

Hơn nữa, tôi phải nói rằng các đánh giá mã thực tế đầu tiên của tôi cũng chứa nhiều bình luận hơn tôi dự kiến ​​ban đầu. Tuy nhiên tôi không bao giờ coi đây là một điều xấu. Nếu bạn tiếp tục học hỏi từ nhận xét của họ² và sẵn sàng áp dụng những kỹ thuật mới / thực tiễn tốt nhất đó trong lần gửi mã trong tương lai của bạn, các nhận xét sẽ trở nên ít hơn. Nó chắc chắn là trường hợp của tôi ;-)

¹ Theo kinh nghiệm của tôi, điều này xảy ra rất nhiều như nhiều lập trình viên tuyên bố php đó là ngôn ngữ lập trình tà ác nhất, có những lập trình viên thiếu kinh nghiệm nhất sử dụng nó. Tôi xa cách với tuyên bố này vì tôi tin rằng phần mềm tuyệt vời có thể được viết bằng bất kỳ ngôn ngữ nào!

² Giả sử rằng mặc dù các ý kiến ​​quá mức, một số giá trị nằm trong đó


Tôi hoàn toàn đồng ý với những gì bạn nói. Đó là một kinh nghiệm học tập và người ta nên học hỏi. Tuy nhiên, điều này đã diễn ra đủ lâu đến một điểm mà dường như không phải như vậy. Hoặc là tôi đang trở nên ngu ngốc hoặc một cái gì đó khác đang diễn ra. Tôi cho rằng nếu mỗi yêu cầu kéo tạo ra 100 bình luận thì bạn sẽ luôn sai hoặc có một điều gì đó khác liên quan ở đây không trùng với những gì họ cho là họ đang cố gắng thực hiện. Hoặc là họ phải nói, "Được rồi, hãy dừng lại và học hỏi" hoặc đi đến điểm chính. Ít nhất đó là cách tôi nhìn thấy nó.
dùng1207047

1
@ user1207047 Sau khi đọc câu trả lời của bạn cho các câu trả lời khác, có vẻ như tôi đã biết câu trả lời cho câu hỏi của chính mình .. :-) Có vẻ như khá rõ ràng rằng có gì đó không hay với đánh giá mã của bạn. Có lẽ đã đến lúc nói chuyện với cấp trên hoặc yêu cầu chuyển sang đội khác?
Jérôme

3

Có ai thường nhận được hơn 100 bình luận trong các bài đánh giá mã của họ trên cơ sở thường xuyên không? Tôi sẽ nói không. Có phải thông thường đối với những người có chất lượng mã "để lại nhiều mong muốn" để nhận được nhiều ý kiến, hoàn toàn.

Tuy nhiên, nó cũng phụ thuộc vào "quy tắc" của quy trình xem xét mã. MỌI NGƯỜI có ý tưởng riêng của họ về cách một cái gì đó nên được thực hiện. Nếu quy trình xem xét mã của bạn cho phép nhận xét ở dạng "Bạn nên thực hiện theo cách này thay vì cách đó", thì bạn có thể sẽ nhận được rất nhiều bình luận ngay cả khi có mã đầy đủ. Nếu quy trình của bạn nhằm tìm "lỗi" thì số lượng bình luận sẽ nhỏ hơn nhiều.

Theo kinh nghiệm của tôi, các đánh giá cho phép "đề xuất" cho các phương pháp thay thế là lãng phí thời gian. Những "gợi ý" đó nên được xử lý từng cái một ngoài quy trình xem xét. Đánh giá khiếm khuyết sẽ hữu ích hơn khi chúng khiến mọi người tập trung vào các lỗi thay vì "tại sao bạn không làm điều đó như tôi sẽ làm?". Nó cũng hữu ích hơn vì không thể phủ nhận một lỗi nếu ai đó tìm thấy. Vì vậy, không có cảm giác tổn thương nhưng có thể biết ơn thay vào đó.

CẬP NHẬT: Với tất cả những gì đã nói, một số mã chỉ đơn giản là xấu, ngay cả khi lỗi miễn phí. Trong trường hợp đó, nhận xét đánh giá nên là một nhận xét duy nhất có nội dung giống như vậy. "Mã này cần được dọn sạch. Vui lòng hoãn đánh giá cho đến khi mã được thảo luận với [tên của bạn ở đây]." Trong trường hợp đó, việc xem xét lại mã sẽ dừng lại cho đến khi nhận xét được khắc phục.

CẬP NHẬT2: @ Người dùng: Bạn có thảo luận về mã / thiết kế của bạn với một trong số họ trong khi bạn đang phát triển nó để bạn có thể thực hiện những gì họ đang tìm kiếm trước khi bạn tiến xa theo cách của mình không? Bạn có thay đổi bất cứ điều gì về cách bạn đang phát triển mã dựa trên đề xuất của họ hoặc tiếp tục nghĩ theo cách của bạn là tốt? Bạn có học được gì từ ý kiến ​​của họ không?

Khi tôi là người dẫn đầu trong một dự án, công việc của tôi là chịu trách nhiệm về TẤT CẢ các sản phẩm công việc. Nếu tôi phê duyệt một sản phẩm làm việc thì tôi khẳng định sản phẩm đó là chấp nhận được. Tôi muốn có một danh tiếng để xây dựng sản phẩm chất lượng. Vì vậy, tôi có kỳ vọng và sẽ không chấp nhận ít hơn thỏa đáng. Đồng thời tôi cố gắng dạy và giải thích lý do cho sở thích của tôi. Những sở thích đó có thể không phải lúc nào cũng lý tưởng (đặc biệt là trong mắt người khác), nhưng hầu hết những sở thích đó đều đến từ kinh nghiệm. Thường là một phản ứng để tránh lặp lại những cái xấu. Vì vậy, có một vài "sticklers" cá nhân của tôi là cần thiết để có được sự chấp thuận của tôi, bất kể đẩy lùi.

Mặt khác, bạn cần học những kỳ vọng cần thiết để sản phẩm công việc của bạn được phê duyệt. Bạn có thể không đồng ý, nhưng vì bạn dường như không có quyền cai trị quá mức, sau đó tìm hiểu những gì được mong đợi. Tôi nghi ngờ rằng nhóm đang cố gắng làm cho bạn thất bại. Vì điều đó làm cho họ trông cũng xấu. Về vấn đề đó, chỉ cần chứng minh rằng bạn rất ham học (ngay cả khi bạn không), hãy nói những gì họ nói và cố gắng hết sức để thích nghi với sở thích của họ và bạn sẽ có thể thấy họ lùi lại khá nhiều. Có thể tìm một người mà bạn ít nhất có thể chịu đựng được và xem liệu họ sẽ làm một chút nắm tay để dạy bạn cách của họ. Ai biết được, trong quá trình bạn có thể học được điều gì đó thực sự có thể đưa kỹ năng của bạn lên một tầm cao mới.


Đồng ý và bạn sẽ không nghe thấy gì về tôi. Tuy nhiên, quá trình không hoàn toàn như thế. Họ nói rằng nó là như vậy, và trong hầu hết các trường hợp, dường như chỉ có những người bên ngoài ba nhóm này chịu sự giám sát nặng nề hơn chính họ. Họ tuyên bố những người khác là nhà phát triển tồi nhưng họ là "nhà phát triển" duy nhất trong nhóm.
dùng1207047

Tuy nhiên, có một điều là nếu bạn không thể hiểu mã hoặc nhà phát triển đã phát minh lại bánh xe thay vì sử dụng một phương thức hiện có hoặc nếu phương thức của anh ta có độ phức tạp theo chu kỳ là 50, thì đó chắc chắn là một trường hợp cho một nhận xét, ngay cả khi không có lỗi Khó đọc mã và sao chép một trách nhiệm pháp lý, ngay cả khi nó không phải là một lỗi. Đó là lý do tại sao tôi không bao giờ ngần ngại chỉ ra rằng một biến được đặt tên kém hoặc giải pháp đưa ra một khớp nối tạm thời làm cho việc hiểu mã khó hơn. Nợ kỹ thuật phải được quản lý.
Laurent Bourgault-Roy

1
@Laurent: Tôi biết bạn đang nói gì và bằng nhiều cách đồng ý. Tuy nhiên, điều đó mở ra một lon giun có xu hướng tuyết. Nếu công ty của bạn có tiền và lịch trình để cho phép đánh giá mã chiếm một phần đáng kể của nỗ lực thì không sao (như các dự án thiết bị y tế / máy bay). Nhưng hầu hết các dự án không có sự sang trọng. Vì vậy, giới hạn phạm vi nhận xét đánh giá là rất hữu ích. Để bù đắp mối quan tâm của bạn, đó là công việc của sw dẫn đến giám sát các nhà phát triển và công việc của họ. Họ nên biết ai giám sát chặt chẽ nhất và khắc phục những vấn đề đó trước khi xem xét mã.
Dunk

Chúng tôi sẽ phải đồng ý không đồng ý ở đây :). Nợ kỹ thuật là thứ mà bạn sẽ phải trả sớm hay muộn (và bạn càng chờ đợi, bạn càng phải trả nhiều tiền lãi). Bạn sẽ không tiết kiệm bất kỳ đồng xu nào đang trì hoãn việc dọn dẹp. Nếu bạn không dành thời gian để dọn dẹp ngay bây giờ, thì thay đổi tiếp theo có thể khiến bạn mất gấp đôi thời gian vì bạn sẽ khó hiểu được mã. Tôi làm việc với một cơ sở mã 8 năm tuổi và sự phát triển đã bị chậm lại do vấn đề chất lượng. Bây giờ chúng ta có một quy tắc "chất lượng nội bộ là không thể phủ định" chính thức. Tôi có thể chứng thực rằng nó đã cứu chúng tôi!
Laurent Bourgault-Roy

Tôi đọc lại bình luận của bạn và tôi nhận ra rằng có lẽ chúng ta có một cách nhìn khác do phương pháp luận của chúng ta. Tôi làm việc trong một nhóm Agile, nơi không có người lãnh đạo. Vì tất cả chúng ta đều bình đẳng và chịu trách nhiệm về chất lượng mã, tất cả chúng ta phải giám sát lẫn nhau. Và xem xét mã được thực hiện mỗi 3-4 giờ trước mỗi lần tích hợp. Vì vậy, làm sạch một yêu cầu kéo lớn là một vài giờ nếu chúng ta rất nazi hoặc nếu chúng ta thực hiện một bộ tái cấu trúc đã ảnh hưởng đến một phần cũ và tồi tệ của phần mềm. Do đó tại sao tôi thấy nhận xét chất lượng mã là "không lớn".
Laurent Bourgault-Roy

2

Một số khác biệt quan trọng với quy trình kiểm tra nhóm của chúng tôi:

  • cơ sở của một cuộc kiểm tra là một danh sách kiểm tra, được biên soạn bởi toàn đội.
  • Trọng tâm là khuyết điểm (hiện tại và tương lai), không phải phong cách vì lợi ích của phong cách.
  • 3 thanh tra (bao gồm cả tác giả) ngồi lại với nhau để chạy qua các bình luận. Chỉ có ý kiến ​​với đa số phiếu bầu vẫn còn.

2

Đối với 50 LỘC 300 bình luận có vẻ hơi quá và - wow - 3 người đánh giá cho mỗi yêu cầu kéo? Công ty của bạn phải có rất nhiều nguồn lực.

Từ kinh nghiệm của tôi cho một quy trình xem xét mã hữu ích, phải có một số quy tắc và / hoặc hướng dẫn:

  • Ưu tiên nhận xét
  • Phân loại ý kiến ​​(Lỗi, Kiểu mã, v.v.)
  • Đồng ý kiến ​​trúc / thiết kế để làm theo
  • Đồng ý kiểu mã

Nếu bạn không nhận được sự ưu tiên từ những người đánh giá, hãy hỏi người quản lý dự án / trưởng nhóm có trách nhiệm của bạn; người chịu trách nhiệm về các chi phí nên có ý kiến ​​về các ưu tiên.

Nếu bạn có kiến ​​trúc đã xác định, hiểu biết chung về các mẫu thiết kế bạn sử dụng trong dự án của bạn và kiểu mã đã đồng ý, thì các nhận xét đánh giá chỉ nên về "các vấn đề thực" như các vấn đề bảo mật, lỗi vô ý, các trường hợp góc không được quy định kiến trúc, v.v.

Nếu nhóm phát triển của bạn không đồng ý về "các vấn đề về hương vị" (ví dụ: nếu một biến thành viên bắt đầu bằng "m_"), thì mọi người đánh giá sẽ buộc bạn tuân theo phong cách của anh ta, điều này chỉ lãng phí thời gian / tiền bạc.


1

Điều này thực sự nghe với tôi như một vấn đề giao tiếp. Bạn có một kỳ vọng rằng mã của bạn không đủ tệ để xứng đáng nhận được 300 bình luận. Các nhà phê bình dường như nghĩ rằng bạn cần rất nhiều phản hồi. Tranh cãi qua lại một cách không đồng bộ sẽ lãng phí rất nhiều thời gian. Heck, viết 300 bình luận là một sự lãng phí thời gian TREMENDOUS. Nếu đây không phải là tất cả các khuyết điểm thì có thể là thành viên nhóm mới mà bạn chưa biết phong cách của đội. Điều đó là bình thường và là thứ nên học để tăng tốc cho cả đội.

Đề nghị của tôi là để tiết kiệm thời gian. Đẩy nhanh phản hồi. Tôi sẽ:

  • Thực hiện thêm các đánh giá tạm thời để tránh mắc lỗi tương tự và tạo cùng một nhận xét 50 lần
  • Ngồi với người đánh giá khi họ xem lại mã của bạn để bạn có thể nói về các vấn đề khi chúng xuất hiện, do đó tránh ghi lại 300 "vấn đề" sẽ bị xóa trong lần xác nhận tiếp theo
  • Ghép nối với một trong những nhà phát triển "thực sự" này một thời gian khi bạn viết mã để xem họ sẽ làm gì khác đi

Mọi người có thể tranh luận về việc ghép đôi vì "sẽ mất nhiều thời gian hơn" nhưng rõ ràng đó không phải là vấn đề ở đây.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.