Khi nào các xác nhận nên ở lại trong mã sản xuất? [đóng cửa]

Có một cuộc thảo luận đang diễn ra tại comp.lang.c ++. Được kiểm duyệt về việc có xác nhận hay không, trong C ++ chỉ tồn tại trong các bản dựng gỡ lỗi theo mặc định, nên được giữ trong mã sản xuất hay không.

Rõ ràng, mỗi dự án là duy nhất, vì vậy câu hỏi của tôi ở đây không phải là quá nhiều liệu có nên giữ các xác nhận hay không, nhưng trong trường hợp này điều này được khuyến khích / không phải là một ý tưởng tốt.

Theo khẳng định, ý tôi là:

• Kiểm tra thời gian chạy kiểm tra một điều kiện, khi sai, sẽ phát hiện ra lỗi trong phần mềm.
• Một cơ chế mà chương trình bị tạm dừng (có thể sau khi thực sự làm sạch tối thiểu).

Tôi không nhất thiết phải nói về C hoặc C ++.

Ý kiến ​​riêng của tôi là nếu bạn là lập trình viên, nhưng không sở hữu dữ liệu (đó là trường hợp của hầu hết các ứng dụng máy tính để bàn thương mại), bạn nên giữ chúng, bởi vì một xác nhận thất bại cho thấy có lỗi và bạn không nên đi với một lỗi, với nguy cơ làm hỏng dữ liệu của người dùng. Điều này buộc bạn phải kiểm tra mạnh mẽ trước khi giao hàng và làm cho các lỗi dễ nhìn thấy hơn, do đó dễ dàng phát hiện và sửa chữa hơn.

Ý kiến ​​/ kinh nghiệm của bạn là gì?

Chúc mừng

Carl

Xem câu hỏi liên quan tại đây

Phản hồi và cập nhật

Này Graham

Một xác nhận là lỗi, thuần túy và đơn giản và do đó nên được xử lý như một. Vì một lỗi nên được xử lý trong chế độ phát hành nên bạn không thực sự cần xác nhận.

Đó là lý do tại sao tôi thích từ "lỗi" khi nói về các xác nhận. Nó làm cho mọi thứ rõ ràng hơn nhiều. Đối với tôi, từ "lỗi" quá mơ hồ. Một tập tin bị thiếu là một lỗi, không phải là một lỗi và chương trình nên xử lý nó. Cố gắng để vô hiệu hóa một con trỏ null là một lỗi và chương trình nên thừa nhận rằng một cái gì đó có mùi như phô mai xấu.

Do đó, bạn nên kiểm tra con trỏ bằng một xác nhận, nhưng sự hiện diện của tệp với mã xử lý lỗi thông thường.

Hơi lạc đề, nhưng một điểm quan trọng trong cuộc thảo luận.

Là một người đứng đầu, nếu các xác nhận của bạn đột nhập vào trình gỡ lỗi khi chúng thất bại, tại sao không. Nhưng có rất nhiều lý do khiến một tập tin không thể tồn tại nằm ngoài tầm kiểm soát của mã của bạn: quyền đọc / ghi, ổ đĩa đầy, thiết bị USB không được cắm, v.v. Vì bạn không kiểm soát được nó, tôi cảm thấy các xác nhận là không phải là cách đúng đắn để đối phó với điều đó.

Carl

Thomas,

Có, tôi có Code Complete và phải nói rằng tôi hoàn toàn không đồng ý với lời khuyên cụ thể đó.

Nói rằng bộ cấp phát bộ nhớ tùy chỉnh của bạn vặn lên và thay đổi một đoạn bộ nhớ vẫn còn được sử dụng bởi một số đối tượng khác. Tôi tình cờ nhận được một con trỏ mà đối tượng này thường xuyên tham gia và một trong những điều bất biến là con trỏ này không bao giờ là null và bạn có một vài xác nhận để đảm bảo rằng nó vẫn giữ nguyên như vậy. Bạn sẽ làm gì nếu con trỏ đột nhiên là null. Bạn chỉ nếu () xung quanh nó, hy vọng rằng nó hoạt động?

Hãy nhớ rằng, chúng ta đang nói về mã sản phẩm ở đây, vì vậy không có sự xâm nhập vào trình gỡ lỗi và kiểm tra trạng thái địa phương. Đây là một lỗi thực sự trên máy của người dùng.

Carl

Khẳng định là những bình luận không trở nên lỗi thời. Họ ghi lại những trạng thái lý thuyết nào được dự định và những trạng thái nào không nên xảy ra. Nếu mã được thay đổi để trạng thái cho phép thay đổi, nhà phát triển sẽ sớm được thông báo và cần cập nhật xác nhận.

Cho phép tôi trích dẫn Mã hoàn thành của Steve McConnell. Phần trên Khẳng định là 8.2.

Thông thường, bạn không muốn người dùng thấy thông báo xác nhận trong mã sản xuất; khẳng định chủ yếu để sử dụng trong quá trình phát triển và bảo trì. Các xác nhận thường được biên dịch thành mã tại thời điểm phát triển và được biên dịch ra khỏi mã để sản xuất.

Tuy nhiên, sau đó trong cùng một phần, lời khuyên này được đưa ra:

Đối với mã rất mạnh, khẳng định và sau đó xử lý lỗi.

Tôi nghĩ rằng miễn là hiệu suất không phải là vấn đề, hãy để lại xác nhận, nhưng thay vì hiển thị một thông báo, hãy ghi nó vào một tệp nhật ký. Tôi nghĩ rằng lời khuyên đó cũng có trong Code Complete, nhưng tôi không tìm thấy nó ngay bây giờ.

Để lại các xác nhận được bật trong mã sản xuất, trừ khi bạn đã đo được rằng chương trình chạy nhanh hơn đáng kể khi chúng bị tắt.

nếu nó không đáng để đo lường để chứng minh nó hiệu quả hơn, thì nó không đáng để hy sinh sự rõ ràng cho một canh bạc hiệu suất. "- Steve McConnell 1993

http://c2.com/cgi/wiki?ShipWithAssertionsOn

Nếu bạn thậm chí nghĩ đến việc để lại các xác nhận trong sản xuất, có lẽ bạn đã nghĩ về chúng sai. Toàn bộ quan điểm của các xác nhận là bạn có thể tắt chúng trong sản xuất, vì chúng không phải là một phần của giải pháp của bạn. Chúng là một công cụ phát triển, được sử dụng để xác minh rằng các giả định của bạn là chính xác. Nhưng thời gian bạn đi vào sản xuất, bạn nên tự tin vào những giả định của mình.

Điều đó nói rằng, có một trường hợp tôi sẽ bật các xác nhận trong sản xuất: Nếu chúng tôi gặp phải một lỗi có thể lặp lại trong sản xuất mà chúng tôi gặp khó khăn trong việc tái tạo trong môi trường thử nghiệm, có thể hữu ích để tái tạo lỗi khi bật các xác nhận trong sản xuất, để xem nếu họ cung cấp thông tin hữu ích.

Một câu hỏi thú vị hơn là: Trong giai đoạn thử nghiệm của bạn, khi nào bạn tắt các xác nhận?

Các xác nhận không bao giờ nên ở trong mã sản xuất. Nếu một xác nhận cụ thể có vẻ như có thể hữu ích trong mã sản xuất, thì đó không phải là một xác nhận; nó nên là một kiểm tra lỗi thời gian chạy, tức là một cái gì đó được mã hóa như thế này : if( condition != expected ) throw exception.

Thuật ngữ 'khẳng định' có nghĩa là "kiểm tra chỉ dành cho thời gian phát triển sẽ không được thực hiện trên sân."

Nếu bạn bắt đầu nghĩ rằng các xác nhận có thể đưa nó vào lĩnh vực thì chắc chắn bạn cũng sẽ bắt đầu thực hiện những suy nghĩ nguy hiểm khác, như tự hỏi liệu bất kỳ khẳng định nào được đưa ra có thực sự đáng để thực hiện hay không. Không có khẳng định nào là không đáng để thực hiện. Bạn không bao giờ nên tự hỏi mình "tôi có nên khẳng định điều này hay không?" Bạn chỉ nên tự hỏi "Có điều gì tôi quên khẳng định không?"

Trừ khi hồ sơ cho thấy rằng các xác nhận đang gây ra vấn đề về hiệu suất, tôi nói họ cũng nên ở lại trong bản phát hành sản xuất.

Tuy nhiên, tôi nghĩ điều này cũng yêu cầu bạn xử lý các thất bại khẳng định một cách duyên dáng. Ví dụ, họ sẽ dẫn đến một loại hộp thoại chung với tùy chọn (tự động) báo cáo vấn đề cho các nhà phát triển, và không chỉ thoát hoặc làm hỏng chương trình. Ngoài ra, bạn nên cẩn thận không sử dụng các xác nhận cho các điều kiện mà bạn thực sự cho phép, nhưng có thể không thích hoặc xem xét không mong muốn. Những điều kiện này nên được xử lý bởi các phần khác của mã.

Trong C ++ của tôi, tôi định nghĩa REQUIRE (x) giống như khẳng định (x) ngoại trừ việc nó ném ngoại lệ nếu xác nhận thất bại trong bản dựng phát hành.

Vì một xác nhận thất bại chỉ ra một lỗi, nên nó được xử lý nghiêm túc ngay cả trong bản dựng Phát hành. Khi hiệu suất mã của tôi có vấn đề, tôi sẽ thường sử dụng REQUIRE () cho mã cấp cao hơn và khẳng định () cho mã cấp thấp hơn phải chạy nhanh. Tôi cũng sử dụng REQUIRE thay vì khẳng định nếu tình trạng lỗi có thể do dữ liệu được truyền từ mã do bên thứ ba viết hoặc do hỏng tệp (tối ưu tôi sẽ thiết kế mã cụ thể để xử lý tốt trong trường hợp hỏng tệp, nhưng chúng tôi đừng luôn có thời gian để làm điều đó.)

Họ nói rằng bạn không nên hiển thị những tin nhắn khẳng định đó cho người dùng cuối vì họ sẽ không hiểu chúng. Vì thế? Người dùng cuối có thể gửi cho bạn một email với ảnh chụp màn hình hoặc một số văn bản của thông báo lỗi, giúp bạn gỡ lỗi. Nếu người dùng chỉ cần nói "nó bị hỏng", bạn có ít khả năng sửa nó hơn. Sẽ tốt hơn nếu bạn tự động gửi tin nhắn xác nhận thất bại qua internet, nhưng điều đó chỉ hoạt động nếu người dùng có quyền truy cập internet và bạn có thể nhận được sự cho phép của họ.

Nếu bạn muốn giữ chúng thay thế chúng với xử lý lỗi. Không có gì tệ hơn một chương trình chỉ biến mất. Tôi thấy không có gì sai khi coi một số lỗi là lỗi nghiêm trọng, nhưng chúng nên được chuyển đến một phần trong chương trình của bạn được trang bị để xử lý chúng bằng cách thu thập dữ liệu, ghi nhật ký và thông báo cho người dùng rằng ứng dụng của bạn có một số điều kiện không mong muốn và đang thoát ra

Miễn là chúng được xử lý như bất kỳ lỗi nào khác, tôi không thấy có vấn đề gì với nó. Hãy nhớ rằng mặc dù các xác nhận thất bại trong C, cũng như các ngôn ngữ khác, sẽ thoát khỏi chương trình và điều này thường không đủ cho các hệ thống sản xuất.

Có một số trường hợp ngoại lệ - ví dụ: PHP, cho phép bạn tạo một trình xử lý tùy chỉnh cho các lỗi xác nhận để bạn có thể hiển thị các lỗi tùy chỉnh, ghi nhật ký chi tiết, v.v. thay vì chỉ thoát.

Phần mềm máy chủ cơ sở dữ liệu của chúng tôi chứa cả các xác nhận gỡ lỗi sản xuất và gỡ lỗi. Các xác nhận gỡ lỗi chỉ là như vậy - chúng được loại bỏ trong mã sản xuất. Khẳng định sản xuất chỉ xảy ra nếu (a) một số điều kiện tồn tại không bao giờ nên tồn tại và (b) không thể phục hồi đáng tin cậy từ điều kiện này. Một xác nhận sản xuất chỉ ra rằng một lỗi trong phần mềm đã gặp phải hoặc một số loại hỏng dữ liệu đã xảy ra.

Vì đây là hệ thống cơ sở dữ liệu và chúng tôi đang lưu trữ dữ liệu có khả năng quan trọng đối với doanh nghiệp, chúng tôi làm mọi cách có thể để tránh dữ liệu bị hỏng. Nếu một điều kiện tồn tại có thể khiến chúng tôi lưu trữ dữ liệu không chính xác, chúng tôi sẽ ngay lập tức xác nhận, khôi phục tất cả các giao dịch và dừng máy chủ.

Có nói rằng, chúng tôi cũng cố gắng tránh các xác nhận sản xuất trong các thói quen quan trọng về hiệu suất.

Tôi thấy các khẳng định như các bài kiểm tra đơn vị nội dòng. Hữu ích cho một bài kiểm tra nhanh trong khi phát triển, nhưng cuối cùng những xác nhận đó nên được tái cấu trúc để được kiểm tra bên ngoài trong các bài kiểm tra đơn vị.

Tôi thấy tốt nhất để xử lý tất cả các lỗi trong phạm vi và sử dụng các xác nhận cho các giả định mà chúng tôi khẳng định là đúng.

tức là, nếu chương trình của bạn đang mở / đọc / đóng tệp, thì không thể mở tệp nằm trong phạm vi - đó là một khả năng thực sự, sẽ là sơ suất để bỏ qua, nói cách khác. Vì vậy, cần phải có mã kiểm tra lỗi liên quan đến nó.

Tuy nhiên, giả sử fopen () của bạn được ghi lại là luôn trả về một tệp xử lý tệp mở, hợp lệ. Bạn mở tệp và chuyển nó đến hàm readfile ().

Hàm readfile đó, trong ngữ cảnh này, và có lẽ theo đặc tả thiết kế của nó, gần như có thể giả định rằng nó sẽ nhận được một tệp ptr hợp lệ. Vì vậy, sẽ rất lãng phí khi thêm mã xử lý lỗi cho trường hợp tiêu cực, trong một chương trình đơn giản như vậy. Tuy nhiên, ít nhất nó nên ghi lại giả định, bằng cách nào đó - đảm bảo bằng cách nào đó --- rằng đây thực sự là trường hợp, trước khi tiếp tục thực hiện. Nó không nên THỰC SỰ giả định rằng sẽ luôn hợp lệ, trong trường hợp nó được gọi không chính xác, hoặc nó được sao chép / dán vào một số chương trình khác, ví dụ.

Vì vậy, readfile () {assert (fptr! = NULL); ..} là thích hợp trong trường hợp này, trong khi xử lý lỗi toàn bộ thì không (bỏ qua thực tế là việc đọc tệp sẽ yêu cầu một số hệ thống xử lý lỗi nào).

Và vâng, những xác nhận đó nên nằm trong mã sản xuất, trừ khi thực sự cần thiết phải vô hiệu hóa chúng. Thậm chí sau đó, có lẽ bạn chỉ nên vô hiệu hóa chúng trong các phần quan trọng về hiệu suất.

Giả sử một đoạn mã đang được sản xuất và nó đạt được một xác nhận thường được kích hoạt. Sự khẳng định đã tìm thấy một lỗi! Ngoại trừ nó không có, bởi vì khẳng định đã bị tắt.

Thế cái gì đang xảy ra vậy? Chương trình sẽ (1) sụp đổ theo cách không chính xác tại một điểm bị loại bỏ thêm khỏi nguồn của vấn đề, hoặc (2) chạy vui vẻ để hoàn thành, có thể cho kết quả sai.

Không kịch bản nào được mời. Để lại các xác nhận hoạt động ngay cả trong sản xuất.

Tôi hiếm khi sử dụng các xác nhận cho bất cứ điều gì khác để biên dịch kiểm tra loại thời gian. Tôi sẽ sử dụng một ngoại lệ thay vì một xác nhận chỉ vì hầu hết các ngôn ngữ được xây dựng để xử lý chúng.

Tôi đưa ra một ví dụ

file = create-some-file();
_throwExceptionIf( file.exists() == false, "FILE DOES NOT EXIST");

chống lại

file = create-some-file();
ASSERT(file.exists());

Làm thế nào ứng dụng sẽ xử lý khẳng định? Tôi thích try catchphương pháp cũ để xử lý các lỗi nghiêm trọng.

Hầu hết thời gian, khi tôi sử dụng khẳng định trong java (từ khóa khẳng định) tôi sẽ tự động thêm một số mã sản xuất sau. Theo trường hợp, nó có thể là một thông điệp đăng nhập, một ngoại lệ ... hoặc không có gì.

Theo tôi, tất cả các xác nhận của bạn là rất quan trọng trong việc phát hành dev, không phải trong quá trình sản xuất. Một số trong số chúng phải được giữ, số khác phải được loại bỏ.

XÁC NHẬN không phải là lỗi và không nên xử lý như lỗi. Khi một xác nhận được đưa ra, điều này có nghĩa là có một lỗi trong mã của bạn hoặc thay vào đó là mã gọi mã của bạn.

Có một vài điểm cần tránh để kích hoạt các xác nhận trong mã sản xuất: 1. Bạn không muốn người dùng cuối của mình nhìn thấy một thông báo như "ASSERTION fail MyPrivateClass.cpp dòng 147. Người dùng cuối KHÔNG phải là kỹ sư QA của bạn. ảnh hưởng đến hiệu suất

Tuy nhiên, có một lý do mạnh mẽ để để lại các xác nhận: ĐÁNH GIÁ có thể ảnh hưởng đến hiệu suất và thời gian, và điều đáng buồn là điều này đôi khi quan trọng (đặc biệt là trong các hệ thống nhúng).

Tôi có xu hướng bỏ phiếu để lại xác nhận trong mã sản xuất nhưng đảm bảo rằng các xác nhận này in ra không được tiếp xúc với người dùng cuối.

~ Yitzik

Một xác nhận là lỗi, thuần túy và đơn giản và do đó nên được xử lý như một.

Vì một lỗi nên được xử lý trong chế độ phát hành nên bạn không thực sự cần xác nhận.

Lợi ích chính mà tôi thấy đối với các xác nhận là một sự phá vỡ có điều kiện - chúng dễ dàng thiết lập hơn nhiều so với việc khoan qua các cửa sổ của VC để thiết lập một cái gì đó cần 1 dòng mã.