Giá trị mặc định - chúng là tốt hay xấu?


12

Câu hỏi về các giá trị mặc định nói chung - giá trị hàm trả về mặc định, giá trị tham số mặc định, logic mặc định khi thiếu thứ gì đó, logic mặc định để xử lý ngoại lệ, logic mặc định để xử lý các điều kiện cạnh, v.v.

Trong một thời gian dài, tôi coi các giá trị mặc định là một thứ "xấu xa thuần túy", một thứ "che giấu thảm họa" và dẫn đến một lỗi rất khó tìm ra. Nhưng gần đây tôi bắt đầu nghĩ về các giá trị mặc định như một loại nợ kỹ thuật ... đó không phải là một điều xấu hoàn toàn mà là thứ có thể cung cấp một số "tài chính ngắn hạn" giúp chúng tôi tồn tại trong dự án (bao nhiêu người trong chúng ta có thể đủ khả năng mua nhà mà không cần thế chấp?).

Khi tôi nói "ngắn hạn" - ý tôi không phải là - "hãy làm điều gì đó nhanh chóng trước và thực hiện tái cấu trúc nó sau đó trước khi nó bắt đầu sản xuất". Không - Tôi đang nói về việc dựa vào các giá trị mặc định được mã hóa cứng trong một phần mềm sản xuất. Cấp - nó có thể gây ra một số vấn đề, nhưng nếu nó chỉ gây ra một rắc rối trong cả năm.

Một lần nữa - tôi đang nói về phần mềm chính "trung bình" ở đây (không phải là phần mềm cho nhà máy điện hạt nhân) - trang web trung bình hoặc ứng dụng UI cho phần mềm kế toán, có nghĩa là mọi người không bị đe dọa, cũng không phải hàng triệu đô la .

Một lần nữa, từ kinh nghiệm của tôi, người dùng doanh nghiệp thà sống với phần mềm "hoạt động bằng cách nào đó", thay vì chờ đợi một phần mềm hoàn hảo. Và việc sử dụng các giá trị mặc định sẽ giúp ích rất nhiều nếu bạn phát triển một phần mềm theo kiểu RAD. Nhưng một lần nữa - các phiên gỡ lỗi dài nhất tôi đã trải qua là do các lỗi được giới thiệu bởi một giá trị mặc định đã dừng là "mặc định" trên đường đi hoặc do một hệ thống con nhỏ gần đây đã được nâng cấp và do nâng cấp này, nó đã không được nâng cấp xử lý chính xác mặc định (ví dụ: danh sách trống so với null hoặc chuỗi null so với chuỗi rỗng).

Vì vậy, câu hỏi của tôi là - là các giá trị mặc định tốt hay xấu. Và nếu chúng là một khoản nợ kỹ thuật - làm thế nào để đo lường số tiền bạn có thể vay để bạn có thể đủ khả năng trả nợ?

Sẽ thực sự đánh giá cao bất kỳ đầu vào.

Chúc mừng.

BIÊN TẬP:

Nếu tôi đang sử dụng các giá trị mặc định như một cách để cắt các góc trong quá trình phát triển - và nếu việc cắt góc dẫn đến lỗi và sự cố - phương pháp để phục hồi từ những vấn đề này là gì?

Câu trả lời:


23

Khái niệm Công ước về Cấu hình là không thể nếu không có các giá trị mặc định hợp lý . Từ khóa ở đây là "hợp lý". Các giá trị mặc định phải có ý nghĩa đối với ít nhất 80% (nếu không nhiều hơn) tất cả việc sử dụng thư viện / dịch vụ / khung.

Quy tắc chung của ngón tay cái:

  • Nếu một giá trị hợp lý cho việc sử dụng 80% trở lên, thì nó cần phải là một giá trị mặc định
  • Nếu không có giá trị nào được sử dụng cho phần lớn các trường hợp, không sử dụng mặc định.
  • Giá trị mặc định ngăn ngừa các lỗi ngu ngốc từ mã thiết lập. Nếu mặc định là hợp lý cho hầu hết các trường hợp, sẽ có ít người gặp rắc rối hơn với cấu hình làm việc.
  • Các cấu hình không chuẩn sẽ hiển thị rõ hơn khi bạn sử dụng mặc định.
  • Mặc định xấu là tồi tệ hơn không có mặc định.

Về cơ bản, một khi bạn tìm hiểu cách cấu hình mặc định hoạt động, bạn có thể đưa ra quyết định có giáo dục về cách thức / thời điểm thực hiện cấu hình không chuẩn.


Cảm ơn đã chỉ cho tôi khái niệm "Công ước về cấu hình". Tôi đã sử dụng nó mà không biết nó có một cái tên. Bạn có thể giải thích quy tắc này: "Cấu hình không chuẩn sẽ hiển thị rõ hơn khi bạn sử dụng mặc định." xin vui lòng.

3
@Andrew nếu có hàng tá cuộc gọi đến Foo()và một cuộc gọi đến Foo("bar"), cuộc gọi đó có xu hướng nổi bật và do đó dễ thấy hơn.
Matthew Scharley

1
Phải, và nếu hầu hết việc sử dụng dịch vụ FTP, hãy sử dụng new FtpService()cổng đặt cổng thay thế sẽ nổi bật ( service.SetPort(12345)).
Berin Loritsch

43

Lấy ví dụ một thư viện thực hiện giao thức FTP. Theo mặc định, FTP dự kiến ​​sẽ hoạt động trên cổng 21. Bây giờ tôi sẽ rất khó chịu nếu tôi phải chỉ định sử dụng cổng 21 mỗi khi tôi xây dựng một đối tượng của một lớp FTP ngẫu nhiên. Nếu tôi cần một cổng khác, hãy để tôi chỉ định.

Mặc định là hoàn toàn tốt khi chúng là mặc định lành mạnh.


21
+1. Lần cuối bạn gõ http://programmers.stackexchange.com:80/questions/?sort=newest&pagesize=50vào thanh địa chỉ là khi nào?
Jörg W Mittag

1
Vì vậy, làm thế nào để bạn đo lường / ước tính / mức độ tỉnh táo của biến mặc định.

5
Mất bao lâu để nghĩ về một giá trị mặc định hợp lý.
Alexander Gessler

1
@Andrew, xem câu trả lời của tôi dưới đây. Nếu một giá trị tốt cho 80% sử dụng trở lên, đó là một mặc định tốt.
Berin Loritsch

2
@Berin Loritsch: Nếu giá trị mặc định được sử dụng cho việc không an toàn, bạn có thể lập luận rằng nó tốt ngay cả khi nó chỉ được sử dụng 1% thời gian.
oosterwal

18

Có lẽ bạn đang sử dụng bố trí bàn phím mặc định với ánh xạ khóa mặc định, ánh xạ nút chuột mặc định, trình duyệt mặc định, nhập ngôn ngữ mặc định của hệ thống, khởi động từ hệ điều hành mặc định trong trình tải khởi động, menu định vị mặc định, lược đồ màu mặc định, phông chữ mặc định chiều rộng / chiều cao / khuôn mặt / kiểu, bộ ký tự mặc định, độ phân giải màn hình mặc định, mặc định ... bạn có ý tưởng.

Nhưng trong tất cả sự nghiêm túc, tôi nghĩ rằng mối quan tâm của bạn không phải là mặc định mà là với thứ khác. Hành vi mặc định vốn không che dấu lỗi. Hầu hết thời gian mã của bạn sẽ chạy trong các điều kiện chung, bất kể bạn có đặt mặc định hay không. Các trường hợp cạnh chưa được xử lý là những điều bạn sẽ muốn đảm bảo rằng bạn tránh bất kể (có lẽ thông qua kiểm tra đầy đủ và đúng cách), khi các mặc định được thay đổi hoặc một tình huống không phổ biến xảy ra.

Ngoài ra, xử lý ngoại lệ "bắt tất cả" được cho là một lỗi thiết kế hơn là bất cứ điều gì bạn có thể gọi là "mặc định".


OK, "bắt tất cả" thực sự là một ví dụ tốt. Vâng - nó đang gây ra rất nhiều đau buồn khi một ngày nào đó có sự cố xảy ra vì một lý do không rõ, và những "số này" không được biết phần lớn bởi vì ngoại lệ thực sự đã bị mất trong một khối bắt tất cả. Vì vậy, nó là một điều xấu - phải không? Mặt khác - không có khối chặn tất cả, phần mềm có thể bị chết hoàn toàn (nếu ngoại lệ không được xử lý) hoặc sẽ yêu cầu logic xử lý lỗi phức tạp (ít nhất là nó sẽ phải ghi lại ngoại lệ và khởi tạo một số dữ liệu bằng một giá trị mặc định).

Vì vậy, để thêm vào câu hỏi ban đầu của tôi - nếu tôi đang sử dụng các giá trị mặc định như một cách để cắt các góc trong quá trình phát triển - và nếu các góc bị cắt dẫn đến lỗi và sự cố - cách tốt nhất để khôi phục từ các vấn đề này là gì?

1
Theo như các trường hợp ngoại lệ, có một bài viết nói rằng nên có một ngoại lệ bắt tất cả cho mỗi luồng , nếu có. Nó sẽ được sử dụng để báo cáo lỗi, vì vậy bạn đang xem chương trình như một "thứ" duy nhất giống như cách mà HĐH sẽ nhìn vào một quy trình. Vì bạn đã có người dùng cuối (và hy vọng các nhà phát triển) trong vòng lặp, nên bạn không thực sự "nuốt" ngoại lệ - vì vậy tất cả đều tốt. Bài viết ở đây: codeproject.com/KB/arch architecture / exbestbestpractices.aspx
Rei Miyasaka

1
Đối với việc sử dụng mặc định để tránh lỗi - làm thế nào về việc sử dụng một nhận xét nhất quán mà bạn có thể kiểm soát + f / mac + f cho? Chẳng hạn, Visual Studio thực sự hiển thị bất kỳ bình luận nào bắt đầu bằng TODO: or TEMP:trong danh sách tác vụ. Nếu tôi từng cắt một góc vì mục đích phát triển, tôi sẽ cố gắng hết sức cẩn thận để đảm bảo rằng tôi đã đặt TODO ở đó - sau đó, thỉnh thoảng, tôi sẽ thực hiện "tìm tất cả" để quay lại và đảm bảo không ai trong số đó được vào bất kỳ bản dựng quan trọng nào.
Rei Miyasaka

Rất tiếc, tôi có nghĩa là sử dụng các giá trị được mã hóa cứng để giúp phát triển. Nhân tiện, tôi mới nhận ra rằng "giá trị được mã hóa cứng" có lẽ là từ bạn đang tìm kiếm, thay vì "giá trị mặc định".
Rei Miyasaka

3

Mặc định nên được sử dụng khi chúng lưu người dùng hoặc nhà phát triển thực hiện các tác vụ lặp đi lặp lại. Chúng không bao giờ được sử dụng để che dấu lỗi hoặc ngoại lệ. Việc sử dụng chúng để ngăn ngừa lỗi không phải là một thực tế xấu, nhưng chỉ chừng nào việc phòng ngừa không che giấu điều gì đó xấu xảy ra. Giá trị mặc định là một công cụ giống như mọi thứ khác. Sử dụng đúng cách chúng có thể giúp bạn tiết kiệm rất nhiều đau đầu và thời gian. Sử dụng không đúng cách họ có thể mang cả nhà xuống.


Giống như C ++ thổi bay toàn bộ chân của bạn ...
Mateen Ulhaq

1
@muntoo: Này, Lisp đã đưa tôi trở lại khập khiễng trong '03.
Joel Etherton

2

Nguyên nhân sâu xa của các vấn đề bạn trích dẫn không phải là giá trị mặc định, mà là các vấn đề tích hợp do thay đổi hợp đồng giao diện, hiểu nhầm và / hoặc giả định không hợp lệ. Về cơ bản, tất cả những điều này (ví dụ cụ thể) dường như là kết quả của giao tiếp không đúng - giữa khách hàng và nhà phát triển hoặc giữa các nhà phát triển / nhóm khác nhau. Đủ công bằng, những vấn đề này có thể biểu hiện dưới dạng giá trị mặc định không hợp lệ, nhưng cũng có vô số dạng khác.

Xử lý nguyên nhân gốc rễ, không phải là triệu chứng.

Và cũng lưu ý rằng - như những người khác đã chỉ ra với các ví dụ tuyệt vời - các giá trị mặc định, khi được sử dụng một cách khôn ngoan, có thể làm cho cuộc sống của người dùng dễ dàng hơn đáng kể. Và đó cuối cùng là mục tiêu của chúng tôi, phải không?


"Giao tiếp không đúng cách" có thể là nguyên nhân gốc rễ, nhưng không phải là nguyên nhân gốc rễ cho hầu hết mọi thứ? Và vì "mục đích cuối cùng của tôi" là cung cấp một phần mềm "đủ tốt" đúng hạn trong môi trường hạn chế về chi phí, tôi muốn biết làm thế nào để nói ra những mặc định xấu / xấu từ những cái tốt.

@Andrew, giao tiếp (hoặc thiếu nó) là một yếu tố chính trong sự thành công / thất bại của một dự án, nhưng không phải là duy nhất. Tuy nhiên, khi đó là thủ phạm, cần xử lý đúng cách, nếu không dự án của bạn gần như chắc chắn sẽ bị tiêu diệt. Tôi không biết về bất kỳ công cụ ma thuật nào để phân tách các mặc định xấu khỏi các công cụ tốt: IMHO yêu cầu phân tích cẩn thận về miền vấn đề, các trường hợp sử dụng, v.v., và, rất nhiều giao tiếp.
Péter Török

0

Các giá trị mặc định không phải là một phần của giao thức / quy ước truyền thông là xấu. Bằng cách "không phải là một phần", ý tôi là họ không được ghi nhận nơi giao thức nghiêm ngặt hoặc đơn giản là họ không mong đợi, nơi giao thức bị lỏng lẻo.

Nếu giá trị mặc định được ghi lại / dự kiến, nó vẫn có thể là xấu, nhưng nó cũng có thể an toàn cho cuộc sống. Nó phụ thuộc vào khu vực miền. Rất thường khi chúng có thể rất nguy hiểm (ví dụ: liều thuốc mặc định, sàn thang máy mặc định, hướng di chuyển mặc định của xe) và đôi khi có thể nguy hiểm nếu không có chúng (ví dụ: hướng di chuyển mặc định của xe, thời gian họp mặc định).

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.