Bạn làm gì khi xem lại mã quá khó?

OK vì vậy rất nhiều đánh giá mã là khá thường xuyên. Nhưng đôi khi có những thay đổi tác động rộng rãi đến mã mong manh, phức tạp hiện có. Trong tình huống này, lượng thời gian cần thiết để xác minh sự an toàn của các thay đổi, không có hồi quy, v.v. là quá mức. Có lẽ thậm chí vượt quá thời gian cần thiết để tự phát triển.

Làm gì trong tình huống này? Hợp nhất và hy vọng không có gì trượt qua? (Không ủng hộ điều đó!) Hãy làm điều tốt nhất có thể và chỉ cố gắng phát hiện ra bất kỳ sai sót rõ ràng nào (có lẽ đây là đánh giá mã nhất nên nhắm đến?) Hợp nhất và kiểm tra kỹ lưỡng như một cách thay thế tốt hơn so với đánh giá mã?

Đây không phải là một câu hỏi cụ thể về việc kiểm tra có nên được thực hiện như là một phần của đánh giá mã hay không. Đây là một câu hỏi đặt ra những lựa chọn tốt nhất trong tình huống như được mô tả, đặc biệt là với thời hạn cuối cùng, không có bộ kiểm tra đơn vị toàn diện nào có sẵn hoặc kiểm tra đơn vị không khả thi đối với mã bị phân mảnh đã thay đổi.

EDIT: Tôi có ấn tượng rằng một vài câu trả lời / nhận xét cho đến nay đã chọn cụm từ "tác động rộng rãi" của tôi và có thể hiểu điều đó có nghĩa là sự thay đổi liên quan đến một số lượng lớn dòng mã. Tôi có thể hiểu đây là cách giải thích, nhưng đó không thực sự là ý định của tôi. Theo "tác động rộng rãi", ý tôi là, ví dụ như tiềm năng hồi quy là rất cao do tính liên kết của cơ sở mã hóa, hoặc phạm vi của các hiệu ứng kích thích, không nhất thiết là bản thân sự thay đổi là lớn. Ví dụ: nhà phát triển có thể tìm cách sửa lỗi với một dòng duy nhất bằng cách gọi một thói quen cấp cao hiện có, xếp tầng các cuộc gọi đến nhiều thói quen cấp thấp hơn. Kiểm tra và xác minh rằng sửa lỗi làm việc là dễ dàng. Xác nhận thủ công (thông qua đánh giá mã) tác động của tất cả các hiệu ứng kích nổ là khó khăn hơn nhiều.

Tiền đề của câu hỏi là, thẳng thắn, đáng kinh ngạc. Chúng tôi cho rằng có một sự thay đổi lớn đối với mã dễ vỡ, phức tạp và đơn giản là không có đủ thời gian để xem xét nó đúng cách . Đây là mã cuối cùng bạn nên dành ít thời gian hơn để xem xét! Câu hỏi này chỉ ra rằng bạn có vấn đề về cấu trúc không chỉ trong chính mã của bạn, mà trong phương pháp quản lý thay đổi của bạn.

Vậy làm thế nào để đối phó với tình huống này? Bắt đầu bằng cách không tham gia vào nó ở nơi đầu tiên:

• Xác định các nguồn phức tạp và áp dụng các phép tái cấu trúc cẩn thận, được xem xét kỹ lưỡng, chính xác để tăng mức độ trừu tượng. Mã này có thể hiểu được bởi một nhân viên mới ra trường, người biết điều gì đó về lĩnh vực kinh doanh của bạn.

• Xác định các nguồn dễ vỡ; điều này có thể bằng cách xem lại mã, bằng cách kiểm tra lịch sử sửa lỗi đối với mã, v.v. Xác định hệ thống con nào dễ vỡ và làm cho chúng mạnh hơn . Thêm logic gỡ lỗi. Thêm các xác nhận. Tạo một triển khai chậm nhưng rõ ràng chính xác của cùng một thuật toán và trong bản dựng gỡ lỗi của bạn, hãy chạy cả hai và xác minh rằng chúng đồng ý. Trong bản dựng gỡ lỗi của bạn, gây ra các tình huống hiếm gặp xảy ra thường xuyên hơn. (Ví dụ: tạo bộ cấp phát bộ nhớ luôn di chuyển một khối trên phân bổ lại hoặc luôn luôn phân bổ một khối ở cuối trang hoặc bất cứ thứ gì.) Làm cho mã mạnh mẽ khi đối mặt với các thay đổi đối với bối cảnh của nó. Bây giờ bạn không có mã dễ vỡ nữa; bây giờ bạn có mã tìm thấy các lỗi, thay vì gây ra các lỗi.

• Viết một bộ các bài kiểm tra tự động. Hiển nhiên, rõ ràng.

• Đừng thay đổi rộng rãi. Thực hiện một loạt các thay đổi nhỏ, nhắm mục tiêu, mỗi thay đổi có thể được xem là chính xác.

Nhưng về cơ bản, kịch bản của bạn là "chúng ta đã tự đào vào một lỗ nợ kỹ thuật và mỗi thay đổi phức tạp, chưa được xem xét sẽ đào sâu chúng ta hơn, chúng ta nên làm gì?". Bạn làm gì khi thấy mình trong cái lỗ đó? Dừng đào . Nếu bạn có quá nhiều nợ đến nỗi bạn không thể thực hiện các nhiệm vụ cơ bản như xem xét mã của nhau thì bạn cần ngừng kiếm thêm nợ và dành thời gian trả hết.

Một trong những mục tiêu chính của đánh giá mã là tăng chất lượng và cung cấp mã mạnh mẽ . Mạnh mẽ, bởi vì 4 mắt thường phát hiện ra nhiều vấn đề hơn 2. Và người đánh giá chưa viết mã bổ sung có nhiều khả năng thách thức các giả định (có khả năng sai).

Tránh đánh giá ngang hàng trong trường hợp của bạn chỉ góp phần làm tăng tính mong manh của mã của bạn. Tất nhiên, tăng cường kiểm tra với một bộ kiểm tra chắc chắn và lặp lại chắc chắn có thể cải thiện chất lượng. Nhưng nó nên được bổ sung để đánh giá ngang hàng, không phải là một sự thay thế .

Tôi nghĩ rằng sự phức tạp phải được hiểu và nắm vững, và đánh giá ngang hàng đầy đủ là dịp để chia sẻ kiến ​​thức và đạt được điều này. Khoản đầu tư bạn thực hiện để có nhiều người hiểu được điểm mạnh và điểm yếu của mã dễ vỡ, sẽ giúp làm cho nó tốt hơn theo thời gian.

Một trích dẫn để kết luận:

"Nếu bạn muốn đi nhanh, hãy đi một mình. Nếu bạn muốn đi xa, hãy đi cùng nhau"

Chào mừng đến với thế giới phát triển phần mềm cũ.

Bạn có 100 nghìn, hàng triệu, 10 triệu triệu dòng mã.

Những dòng mã này có giá trị, trong đó chúng tạo ra một luồng doanh thu và thay thế chúng là không thể thực hiện được.

Mô hình kinh doanh của bạn dựa trên việc tận dụng cơ sở mã đó. Vì vậy, nhóm của bạn nhỏ, cơ sở mã lớn. Việc thêm các tính năng là bắt buộc để khiến mọi người mua phiên bản mới của mã của bạn hoặc để giữ cho khách hàng hiện tại hài lòng.

Trong một thế giới hoàn hảo, cơ sở mã khổng lồ của bạn là đơn vị đã thử nghiệm wazoo. Bạn không sống trong một thế giới hoàn hảo.

Trong một thế giới kém hoàn hảo, bạn có ngân sách để khắc phục khoản nợ kỹ thuật của mình - chia mã của bạn thành các phần có thể kiểm tra đơn vị, thực hiện kiểm tra tích hợp mở rộng và lặp lại.

Điều này, tuy nhiên, đang trả nợ mà không tạo ra các tính năng mới. Điều này không phù hợp với trường hợp kinh doanh "gặt hái lợi nhuận từ mã hiện có, trong khi sửa đổi nó để tạo ra động lực để nâng cấp".

Bạn có thể lấy những đoạn mã lớn và viết lại bằng các kỹ thuật hiện đại hơn. Nhưng ở mọi nơi bạn tương tác với mã hiện tại, bạn sẽ phơi bày các điểm dừng có thể. Sự hack đó trong hệ thống mà bạn đã loại bỏ thực sự đã bù đắp cho một sự cố trong hệ thống con mà bạn không viết lại. Luôn luôn.

Những gì bạn có thể làm là hành động cẩn thận. Bạn có thể tìm thấy một phần của mã mà bạn thực sự hiểu và hành vi cũng như tương tác với phần còn lại của hệ thống cũng được hiểu rõ. Bạn có thể hiện đại hóa điều đó, thêm các bài kiểm tra đơn vị và làm cho hành vi của nó thậm chí rõ ràng hơn.

Sau đó tìm các phần của phần còn lại của ứng dụng chủ yếu tương tác với nó và tấn công từng phần một.

Khi bạn làm như vậy, bạn có thể cải thiện hệ thống con, thêm các tính năng mà khách hàng sẵn sàng trả tiền.

Nói tóm lại, đây là nghệ thuật có thể - thực hiện các thay đổi mà không phá vỡ những thứ cung cấp cho một trường hợp kinh doanh.

Nhưng đây không phải là câu hỏi của bạn. Câu hỏi của bạn là, "Tôi đang làm một cái gì đó rất lớn, và có khả năng phá vỡ mọi thứ, và làm thế nào để tôi làm theo các thực tiễn tốt nhất?"

Khi làm một việc gì đó rất lớn, sự thật là nếu bạn muốn làm điều đó một cách đáng tin cậy thì cuối cùng bạn sẽ dành nhiều nỗ lực hơn để theo dõi các lỗi và sửa chúng hơn là bạn viết nó. Đây là quy tắc chung của phát triển phần mềm: viết công cụ rất dễ, làm cho nó hoạt động hoàn hảo là khó.

Bạn có thể có một trường hợp kinh doanh treo trên đầu, nơi bạn đã hứa với một số bên liên quan rằng sự thay đổi lớn này xảy ra. Và nó đã được thực hiện, vì vậy bạn bị đẩy lùi khi nói "không, điều này không được thực hiện, nó chỉ có vẻ thích nó ".

Nếu bạn có sức mạnh và ngân sách, thực sự dành nỗ lực tạo niềm tin rằng thay đổi hoạt động hoặc đơn giản là từ chối thay đổi. Đây sẽ là một vấn đề bằng cấp, không tử tế.

Nếu bạn không có nhiều năng lượng như vậy, nhưng vẫn có một số, hãy cố gắng nhấn mạnh rằng hệ thống mới có thể kiểm tra được . Nếu bạn viết lại một số hệ thống con, hãy nhấn mạnh rằng hệ thống con mới này bao gồm các phần nhỏ với các kiểm tra đơn vị và hành vi được chỉ định tốt xung quanh chúng.

Sau đó là trường hợp xấu nhất. Bạn đi sâu hơn vào nợ nần. Bạn vay mượn tương lai của chương trình bằng cách có nhiều mã dễ vỡ hơn và nhiều lỗi hơn để có được tính năng này ngay bây giờ và gây hậu quả. Bạn thực hiện QA dựa trên quét để tìm các vấn đề tồi tệ nhất và bỏ qua phần còn lại. Đây thực sự đôi khi là câu trả lời đúng từ quan điểm của doanh nghiệp, vì nó rẻ nhất bây giờ. Đi vào nợ để tạo ra lợi nhuận là một chiến lược kinh doanh hợp lệ, đặc biệt là nếu xóa nợ thông qua phá sản (từ bỏ mã) là trên bàn.

Một vấn đề lớn là hiếm khi các ưu đãi của các chủ sở hữu công ty phù hợp với những người ra quyết định và lập trình viên. Có xu hướng được rất nhiều áp lực để 'giao', và làm như vậy bằng cách tạo ra gần như vô hình (với cấp trên của bạn) nợ kỹ thuật là một vĩ đại chiến lược ngắn và đôi khi trung hạn. Ngay cả khi cấp trên / các bên liên quan của bạn sẽ được phục vụ tốt nhất bằng cách không tạo ra tất cả các khoản nợ đó.

Giải quyết các vấn đề lớn hơn đang khiến việc đánh giá mã trở nên quá khó khăn.

Những cái mà tôi đã phát hiện cho đến nay:

1. Không có bộ kiểm tra đơn vị
2. Hợp nhất mã phức tạp có thể tránh được bằng cấu trúc mã hợp lý hơn và ủy thác nhiệm vụ mã hóa
3. Rõ ràng là thiếu kiến ​​trúc thô sơ

1. Bạn có thể gửi lại đánh giá mã và yêu cầu nhà phát triển chia nó thành các thay đổi nhỏ hơn, gia tăng hơn và gửi đánh giá mã nhỏ hơn.

2. Bạn vẫn có thể kiểm tra mùi mã, mẫu và chống mẫu, tiêu chuẩn định dạng mã, nguyên tắc RẮN, v.v. mà không nhất thiết phải xem qua từng chi tiết của mã.

3. Bạn vẫn có thể thực hiện kiểm tra mã chiến thuật để xác thực đầu vào thích hợp, quản lý khóa / luồng, ngoại lệ có thể xử lý, v.v. ở mức chi tiết, mà không nhất thiết phải hiểu ý định chung của toàn bộ thay đổi.

4. Bạn có thể đưa ra đánh giá về các khu vực rủi ro tổng thể mà bạn biết có thể bị ảnh hưởng bởi mã và yêu cầu nhà phát triển xác nhận rằng các khu vực rủi ro này đã được kiểm tra đơn vị (hoặc yêu cầu anh ta viết các bài kiểm tra đơn vị tự động và cũng gửi chúng để xem xét ).

Trong tình huống này, lượng thời gian cần thiết để xác minh sự an toàn của các thay đổi, không có hồi quy, v.v. là quá mức.

Đánh giá mã không nên chủ yếu nhằm mục đích chính xác. Họ ở đây để cải thiện khả năng đọc mã, khả năng duy trì và tuân thủ các tiêu chuẩn nhóm.

Tìm lỗi chính xác trong quá trình đánh giá mã là một sản phẩm phụ tuyệt vời để thực hiện chúng, nhưng nhà phát triển nên đảm bảo mã của họ hoạt động hoàn hảo (bao gồm cả không hồi quy) trước khi gửi nó để xem xét .

Sự đúng đắn nên được xây dựng ngay từ đầu. Nếu một nhà phát triển không thể đạt được nó, hãy yêu cầu họ lập trình chương trình hoặc vạch ra một kế hoạch với cả nhóm nhưng đừng coi đó là thứ bạn có thể thêm vào như một suy nghĩ sau.

Nếu bạn nghĩ rằng việc xem xét mã là quá khó, bởi vì nó đã thay đổi mã giòn gần như không thể thay đổi mà không phá vỡ nó, thì bạn có một vấn đề. Nhưng vấn đề không nằm ở việc xem lại mã. Vấn đề cũng không phải là với các bài kiểm tra đơn vị, bởi vì mã giòn không thể được kiểm tra đơn vị! Nếu mã của bạn là đơn vị có thể kiểm tra được thì nó sẽ được chia thành các đơn vị nhỏ, độc lập, mỗi đơn vị có thể được kiểm tra và hoạt động tốt với nhau, và đó chính xác là những gì bạn không có!

Vì vậy, bạn có một đống mã rác (còn gọi là "nợ kỹ thuật"). Điều tồi tệ nhất bạn có thể làm là bắt đầu sửa chữa đống rác đó và không hoàn thành công việc vì theo cách đó bạn sẽ nhận được một đống mã rác thậm chí còn lớn hơn. Vì vậy, điều đầu tiên là làm cho quản lý của bạn mua để sửa nó và hoàn thành công việc. Hoặc bạn không. Trong trường hợp đó, bạn không chạm vào nó.

Khi bạn sửa nó, bạn trích xuất một đơn vị từ mã, biến nó thành một thứ có hành vi được xác định rõ ràng và được ghi chép rõ ràng, viết các bài kiểm tra đơn vị cho đơn vị đó, xem lại mã và cầu nguyện rằng không có gì phá vỡ. Và sau đó bạn làm tương tự với đơn vị tiếp theo, v.v.

Một chút khó khăn đến khi bạn gặp phải lỗi. Tổ chuột của bạn sẽ làm những điều sai trong một số trường hợp bởi vì mọi thứ rất dễ vỡ và phức tạp, mọi thứ sẽ đi sai. Khi bạn trích xuất các đơn vị, mã còn lại sẽ trở nên rõ ràng hơn. (Tôi đã gặp trường hợp sau khi tái cấu trúc, một hàm bắt đầu bằng "if (condition1 && condition2 && condition3) crash ();" chính xác là hành vi trước khi tái cấu trúc, chỉ rõ ràng hơn. hành vi kỳ lạ và không mong muốn rõ ràng, vì vậy bạn có thể khắc phục nó. Mặt khác, đó là nơi bạn phải thay đổi hành vi của mã hiện có, do đó cần phải được thực hiện cẩn thận).

Thật không may, thực sự bạn không thể làm gì nhiều về vấn đề này ở điểm đánh giá mã ngoài việc lấy một tách cà phê khác. Giải pháp thực tế cho vấn đề này là giải quyết các khoản nợ kỹ thuật bạn đã tích lũy: thiết kế mỏng manh, thiếu các bài kiểm tra. Hy vọng rằng, bạn ít nhất có một số loại QA chức năng. Nếu bạn không có điều đó thì luôn luôn cầu nguyện cho một số xương gà.

Nếu bạn không hài lòng với phần mềm bị lỗi / không hoạt động và sửa nó sau, thì nỗ lực của V & V NÊN dài hơn nỗ lực phát triển!

Nếu mã hiện tại là dễ vỡ, thì câu hỏi đầu tiên là "bạn thậm chí có nên thay đổi nó không?" Ban quản lý cần thực hiện một cuộc gọi về việc liệu chi phí / rủi ro của việc thiết kế lại và thực hiện lại mã này có lớn hơn chi phí / rủi ro trong việc sửa chữa đống rác lung lay hay không. Nếu nó là một lần, có thể dễ dàng hơn để vá nó. Nếu có khả năng sẽ có nhiều thay đổi cần thiết hơn trong tương lai, thực hiện cú đánh ngay bây giờ để tránh đau đớn hơn trong tương lai có thể là một quyết định tốt hơn. Bạn cần phải nâng cao điều này với quản lý của bạn, bởi vì cung cấp cho người quản lý của bạn thông tin tốt là một phần công việc của bạn. Họ cần phải đưa ra quyết định đó, bởi vì đó là một quyết định chiến lược cao hơn mức trách nhiệm của bạn.

Từ kinh nghiệm của tôi, tôi thực sự khuyên bạn nên bao gồm mã của mình với một số lượng thử nghiệm hợp lý, cả đơn vị và tích hợp, TRƯỚC KHI bất kỳ thay đổi nào được thực hiện đối với hệ thống được đề cập. Điều quan trọng cần nhớ là ngày nay có rất nhiều công cụ cho mục đích đó, không quan trọng ngôn ngữ bạn đang phát triển.

Ngoài ra, có công cụ của tất cả các công cụ để bạn tạo các bài kiểm tra tích hợp của mình. Vâng, tôi đang nói về các container và đặc biệt là Docker và Docker Compose . Nó cung cấp cho chúng ta một cách nhanh chóng để thiết lập một môi trường ứng dụng phức tạp, với cơ sở hạ tầng (cơ sở dữ liệu, mongodb, máy chủ xếp hàng, v.v.) và các ứng dụng.

Các công cụ có sẵn, sử dụng chúng! :)

Tôi không biết tại sao nó chưa được đề cập đến, nhưng 2 điều này là những phần quan trọng nhất:

• Bạn chia phần thay đổi thành nhiều phần thay đổi nhỏ hơn, sau đó bạn xem lại từng phần một. *
• Nếu việc xem xét một người thay đổi không dẫn đến một quyết định rằng người thay đổi đó có vẻ tốt, rõ ràng bạn từ chối sự thay đổi.

* Ví dụ: Bạn thay thế thư viện A bằng thư viện B. Một người thay đổi giới thiệu thư viện B, nhiều người thay đổi khác nhau thay thế việc sử dụng A bằng B từng mảnh (ví dụ: một thay đổi trên mỗi mô-đun) và người thay đổi cuối cùng xóa thư viện A.

Làm điều tốt nhất có thể và chỉ cố gắng phát hiện ra bất kỳ sai sót rõ ràng nào (có lẽ đây là bài đánh giá mã nhất nên nhắm đến dù sao)?

Đừng đánh giá thấp giá trị tiềm năng của mã sửa đổi. Họ có thể giỏi phát hiện lỗi:

• Tìm các lỗi khó phát hiện mặc dù đang thử nghiệm
• Tìm các lỗi khó xác định / sửa chữa mặc dù đang thử nghiệm

Chúng cũng hữu ích vì những lý do khác:

• Trợ giúp để đào tạo thành viên của đội
• Giúp đảm bảo rằng mã đáp ứng các số liệu chất lượng khác, ví dụ như giúp đảm bảo rằng nó dễ hiểu và có thể bảo trì và không chỉ không có lỗi

Làm gì trong tình huống này?

Trong trường hợp tốt nhất / lý tưởng, việc kiểm tra mã không chỉ có nghĩa là "không có lỗi rõ ràng": nó có nghĩa là "rõ ràng không có lỗi" (mặc dù tất nhiên bạn cũng muốn kiểm tra nó).

Nếu bạn không thể xác minh cơ sở mã mới thông qua kiểm tra mã thì nó sẽ cần thử nghiệm "hộp đen" rộng rãi hơn. Bạn có thể đã quen với một chu kỳ phát triển nơi bạn đưa mã vào sản xuất sau khi nó được kiểm tra, nhưng nếu nó không thể "vượt qua kiểm tra" thì bạn không thể "đưa nó vào sản xuất" và nó cần một chu kỳ dài hơn: ví dụ: kiểm tra tích hợp , kiểm tra hệ thống, kiểm tra alpha, kiểm tra chấp nhận, kiểm tra beta, v.v.

không có bộ kiểm thử đơn vị toàn diện có sẵn hoặc kiểm tra đơn vị không khả thi đối với mã bị phân mảnh đã thay đổi

Điều gì về các bài kiểm tra tích hợp, hệ thống, và chấp nhận?

Dù sao, bạn có lẽ nên nói với người quản lý dự án và người quản lý sản phẩm rằng mã gần như chắc chắn có lỗi, với một số lỗi không xác định; và rằng họ sẽ "có được những gì họ kiểm tra" thay vì chỉ nhận được "những gì họ mong đợi" - tức là chất lượng mã không tốt hơn thử nghiệm của họ (vì chất lượng mã chưa được và không thể được đảm bảo bằng kiểm tra mã) .

Họ có thể nên chuyển tiếp tin nhắn đó đến khách hàng hoặc người dùng, để họ thực hiện thử nghiệm beta (nếu họ sẵn sàng là người chấp nhận sớm) hoặc sử dụng phiên bản cũ hơn cho đến khi phiên bản mới hết beta (nếu không phải là phiên bản beta).

Rất nhiều mã được viết và hợp nhất mà không cần xem xét mã thích hợp. Nó có thể làm việc. Có một lý do tại sao nó được gọi là mùi mã không phải là "mã bị hỏng" hoặc một cái gì đó cho hiệu ứng đó. Việc thiếu đánh giá mã là một dấu hiệu cảnh báo, không phải là điềm báo về sự diệt vong.

Giải pháp cho vấn đề này là không có một giải pháp nào phù hợp với tất cả các trường hợp mà chúng ta có thể đóng gói vào câu trả lời kiểu StackExchange. Đó là sự đồng thuận mạnh mẽ của cộng đồng phát triển phần mềm rằng đánh giá mã là một "thực tiễn tốt nhất" quan trọng, và trong trường hợp này nó đang bị bỏ qua. Sự phát triển của bạn không còn nằm trong kênh hẹp "tuân theo tất cả các thực tiễn tốt nhất". Bạn sẽ cần phải tìm ra con đường của riêng bạn.

Dù sao "thực hành tốt nhất" là gì? Khi bạn hiểu đúng về nó, đó là một tập hợp mà mọi người thường nghĩ làm cho mã tốt hơn. Họ có làm mã đúng không? Quái gì không! Internet tràn ngập những câu chuyện từ các công ty tuân theo "thực tiễn tốt nhất" và bị kẹt bởi nó. Có lẽ một quan điểm tốt hơn về "thực tiễn tốt nhất" là chúng là giải pháp "lửa và quên" của thế giới phần mềm. Tôi không thể biết gì về công ty của bạn, dự án của bạn, nhóm của bạn và có thể loại bỏ "các thực tiễn tốt nhất" như những điều sẽ giúp bạn hiểu. Họ là những lời khuyên "không làm hại" chung.

Bạn đã đi chệch khỏi kế hoạch này rõ ràng. May mắn thay, bạn nhận ra nó. Làm tốt lắm! Họ nói kiến ​​thức là một nửa trận chiến; Nếu vậy, nhận thức là hơn một nửa của nó! Bây giờ một giải pháp là cần thiết. Từ mô tả của bạn, rõ ràng môi trường kinh doanh bạn đang phát triển đến mức lời khuyên nhàm chán về "hãy thực hiện đánh giá mã, đó là cách thực hành tốt nhất" sẽ không cắt giảm. Đối với điều này, tôi khuyến nghị một quy tắc chính mà tôi sử dụng khi nói đến thực tiễn tốt nhất về phần mềm:

Không có phần mềm phát triển thực hành tốt nhất hơn hẳn một nhu cầu kinh doanh.

Thành thật mà nói, họ đang trả tiền lương của bạn và sự sống còn của doanh nghiệp thường quan trọng hơn nhiều so với chất lượng của phần mềm. Chúng tôi không muốn thừa nhận nó, nhưng phần mềm được viết hoàn hảo là vô ích nếu nó bị mắc kẹt trong cơ thể của một công ty chết vì nỗ lực duy trì phần mềm được viết hoàn hảo đó.

Vậy bạn đi đâu Theo dấu vết của lực lượng. Bạn đã chỉ ra rằng, vì một số lý do không có căn cứ, việc trải qua đánh giá mã cho một số nhiệm vụ là không hợp lý. Theo kinh nghiệm của tôi, lý do đó luôn luôn là tạm thời. Luôn luôn là "không đủ thời gian" hoặc "không đủ tiền để giữ mức lương chảy trong khi bạn dành thời gian." Đây là kinh doanh; không sao đâu Nếu nó đã được dễ dàng, tất cả mọi người sẽ làm điều đó. Theo dõi lực lượng đi lên và tìm quản lý ở vị trí để giúp bạn hiểu lý do tại sao đánh giá mã không phải là một tùy chọn. Ngôn ngữ là khó, và thường thì một nghị định sẽ chảy xuống từ quản lý cấp trên và bị bóp méo. Giải pháp cho vấn đề của bạn có thể bị ẩn trong sự biến dạng đó.

Câu trả lời cho điều này là, nhất thiết, một kịch bản trường hợp cụ thể. Nó giống như cố gắng dự đoán xem việc tung đồng xu sẽ là đầu hay đuôi. Các thực tiễn tốt nhất nói là lật nó 100 lần và kỳ vọng sẽ có khoảng 50 đầu và 50 đuôi, nhưng bạn không có thời gian để lật nó 1 lần. Đây là nơi chi tiết về tình huống của bạn. Bạn có biết rằng một đồng xu thường sẽ rơi theo cùng một hướng mà nó đã được ném từ khoảng 51% thời gian không? Bạn đã dành thời gian để quan sát xem đồng xu đã được tung ra như thế nào trước khi tung? Nó có thể làm cho một sự khác biệt.

Một giải pháp chung có thể có sẵn cho bạn là cố gắng tìm cách rút ra quy trình xem xét mã và biến nó thành một nỗ lực chi phí rất thấp. Phần lớn chi phí của quy trình xem xét mã là mọi người đều dành 100% cho việc xem xét mã trong khi bạn đang thực hiện. Điều này phải là trường hợp bởi vì, một khi việc xem xét mã được thực hiện, mã được ban phước. Có lẽ bạn có thể đặt mã ở một nhánh khác và thực hiện đánh giá mã song song với phát triển trên thân chính. Hoặc có lẽ bạn thậm chí có thể thiết lập nó để phần mềm thực hiện kiểm tra cho bạn. Có thể bạn đang ở trong môi trường kinh doanh nơi khách hàng của bạn có thể chạy mã "mới" song song với mã cũ và để họ so sánh kết quả. Điều này biến khách hàng thành một loạt các thiết bị tạo trường hợp sử dụng.

Một chìa khóa cho tất cả các "maybes" đang chạy này là bạn nên cố gắng làm cho mã của bạn dễ dàng bị chia thành từng mảnh. Bạn có thể "chứng minh" các đoạn mã mà không cần dựa vào đánh giá mã chính thức bằng cách sử dụng chúng trong các dự án quan trọng ít nhiệm vụ hơn. Sẽ dễ dàng hơn để làm điều này nếu các thay đổi ở dạng nhỏ hơn, ngay cả khi tổng số của chúng quá lớn để đánh giá ngang hàng.

Nói chung, tìm kiếm các giải pháp cụ thể cho dự án của bạn, công ty của bạn, nhóm của bạn. Câu trả lời cho mục đích chung là "thực hành tốt nhất". Bạn không sử dụng những thứ đó, vì vậy bạn nên tìm kiếm các giải pháp tùy chỉnh hơn cho vấn đề này, lần này. Đây là kinh doanh. Nếu mọi thứ diễn ra theo cách chúng ta mong đợi mọi lúc, IPO sẽ dễ dàng hơn rất nhiều để gán giá trị cho, phải không!

Nếu việc thay thế đánh giá mã là một cuộc đấu tranh, hãy nhớ rằng chưa bao giờ có một đoạn mã nào được chứng minh là hoạt động trong đánh giá mã. * Tất cả đánh giá mã là giúp bạn tự tin vào mã và có cơ hội sửa lỗi trước khi chúng trở thành một vấn đề. Cả hai sản phẩm có giá trị này của một đánh giá mã có thể được mua bằng các phương tiện khác. Đánh giá mã chỉ có một giá trị được công nhận là đặc biệt tốt về nó.

* Chà, gần như: hạt nhân L4 đã nhận được mã đánh giá một thời gian trước bởi một hệ thống chứng minh tự động chứng minh mã của nó, nếu được biên dịch bởi trình biên dịch C ++ tuân thủ, sẽ thực hiện chính xác những gì tài liệu nói.

Như @EricLippert chỉ ra trong câu trả lời xuất sắc của mình, loại thay đổi này cần được chú ý nhiều hơn chứ không phải ít hơn . Nếu bạn nhận ra một thay đổi mà bạn đang thực hiện sẽ trở thành một thay đổi như vậy, có một vài chiến lược có thể giúp:

• Cam kết kiểm soát phiên bản thường xuyên. Việc xem xét có thể tiến triển trên cơ sở cam kết bằng cam kết và có thể dễ hiểu hơn khi bạn có các cam kết nhỏ hơn.
• Hãy chắc chắn rằng bạn nhận xét lý do cho mỗi thay đổi càng rõ ràng càng tốt.
• Nếu hoàn toàn hợp lý, hãy sử dụng lập trình cặp cho loại thay đổi này. Có ba mắt về vấn đề thay vì 2 có thể giúp tránh các vấn đề có thể bị bỏ qua bình thường và có một cặp trong khi bạn đang làm việc có thể giúp bạn cải thiện bất kỳ nhận xét nào về mã mà bạn nghĩ là rõ ràng nhưng hóa ra lại ít rõ ràng hơn hơn bạn tin, điều này sẽ giúp người đánh giá sau này. Sự giúp đỡ trong (a) giảm lỗi trong quá trình phát triển và (b) tài liệu được cải thiện thực sự có nghĩa là có ít thời gian dành cho việc này hơn, mặc dù có nhiều người tham gia hơn.

Nhiều câu trả lời đang giải quyết làm thế nào bạn đạt đến điểm này. Nhiều người trong số họ đưa ra một số gợi ý để khắc phục tình hình, nhưng tôi muốn ném câu trả lời của mình vào để đưa ra câu trả lời ngắn.

Phải làm gì khi đánh giá mã "quá khó?"

1. Quay trở lại nhánh mã dòng chính
2. Viết bài kiểm tra cho chức năng bạn đã tái cấu trúc (ví dụ: kiểm tra chức năng)
3. Làm bài kiểm tra để vượt qua
4. Hợp nhất các bài kiểm tra vào mã "khó kiểm tra"
5. Làm các bài kiểm tra vẫn vượt qua?

Đúng

Các nhà phát triển của bạn thật tuyệt! Mèo trở lại cho mọi người!

(hoặc cho những người không lớn lên xem " The Simpsons " trên truyền hình Hoa Kỳ: Nếu các bài kiểm tra đang trôi qua, hãy bỏ qua việc xem xét sự khác biệt và để nhà phát triển dẫn bạn đi tham quan các thay đổi)

Không

Tiếp tục tái cấu trúc và thêm phạm vi kiểm tra cho đến khi các bài kiểm tra được thông qua.

Giống như phép nhân, đánh giá mã cho kết quả bằng 0 khi áp dụng cho số không. Nó không làm tăng giá trị trong trường hợp đó, trong khi trong hầu hết các trường hợp khác thì nó sẽ như vậy.

Mã bạn cần làm việc với thiết kế quá tệ để hưởng lợi từ quá trình xem xét mã trong quá trình phát triển hơn nữa. Sử dụng quy trình xem xét mã để cấu trúc lại hoặc phát triển lại nó.

Nó cũng có thể là mã vẫn có thể chịu được nhưng nhiệm vụ không tốt. Nó quá rộng và nên được thực hiện với số lượng nhỏ hơn.