Có tự do trong những gì bạn chấp nhận hay không?

[Tuyên bố miễn trừ trách nhiệm: câu hỏi này mang tính chủ quan, nhưng tôi muốn nhận được câu trả lời được hỗ trợ bởi các sự kiện và / hoặc phản xạ]

Tôi nghĩ mọi người đều biết về Nguyên tắc Mạnh mẽ , thường được tóm tắt bởi Luật Postel:

Hãy thận trọng trong những gì bạn gửi; Hãy tự do trong những gì bạn chấp nhận.

Tôi đồng ý rằng đối với việc thiết kế giao thức truyền thông rộng rãi, điều này có thể có ý nghĩa (với mục tiêu cho phép mở rộng dễ dàng), tuy nhiên tôi luôn nghĩ rằng ứng dụng của nó đối với HTML / CSS là một sự thất bại hoàn toàn, mỗi trình duyệt thực hiện một chỉnh sửa im lặng của riêng mình phát hiện / hành vi, khiến gần như không thể có được kết xuất nhất quán trên nhiều trình duyệt.

Mặc dù vậy, tôi lưu ý rằng RFC của giao thức TCP có thể chấp nhận "Thất bại thầm lặng" trừ khi có quy định khác ... đó là một hành vi thú vị, để nói rằng ít nhất.

Có những ví dụ khác về việc áp dụng nguyên tắc này trong suốt giao dịch phần mềm thường xuyên bật lên vì họ đã cắn các nhà phát triển, từ đầu tôi ra khỏi đầu:

• Javascript chèn dấu hai chấm
• Chuyển đổi dựng sẵn C (im lặng) (sẽ không quá tệ nếu nó không bị cắt cụt ...)

và có các công cụ để giúp thực hiện hành vi "thông minh":

• tên phù hợp với thuật toán ngữ âm ( Double Metaphone )
• thuật toán khoảng cách chuỗi ( khoảng cách Levenshtein )

Tuy nhiên, tôi thấy rằng cách tiếp cận này, mặc dù có thể hữu ích khi giao dịch với người dùng không có kỹ thuật hoặc để giúp người dùng trong quá trình khôi phục lỗi, có một số nhược điểm khi áp dụng cho thiết kế giao diện thư viện / lớp:

• nó hơi chủ quan cho dù thuật toán đoán "đúng", và do đó nó có thể đi ngược lại Nguyên lý tối thiểu
• nó làm cho việc triển khai trở nên khó khăn hơn, do đó có nhiều cơ hội hơn để giới thiệu các lỗi (vi phạm YAGNI ?)
• nó làm cho hành vi dễ bị thay đổi hơn, vì bất kỳ sửa đổi nào của thói quen "đoán" có thể phá vỡ các chương trình cũ, gần như loại trừ khả năng tái cấu trúc ... ngay từ đầu!

Và đây là những gì dẫn tôi đến câu hỏi sau đây:

Khi thiết kế một giao diện (thư viện, lớp, tin nhắn), bạn có nghiêng về nguyên tắc mạnh mẽ hay không?

Bản thân tôi có xu hướng khá nghiêm ngặt, sử dụng xác nhận đầu vào rộng rãi trên các giao diện của mình và tôi tự hỏi liệu có lẽ tôi quá nghiêm ngặt.

Tôi sẽ nói mạnh mẽ khi nó không giới thiệu sự mơ hồ .

Ví dụ: Khi phân tích danh sách được phân tách bằng dấu phẩy, có hay không một khoảng trắng trước / sau dấu phẩy không thay đổi ý nghĩa ngữ nghĩa.

Khi phân tích một hướng dẫn chuỗi, nó phải chấp nhận bất kỳ số lượng định dạng phổ biến nào (có hoặc không có dấu gạch ngang, có hoặc không có dấu ngoặc nhọn bao quanh).

Hầu hết các ngôn ngữ lập trình đều mạnh mẽ với việc sử dụng khoảng trắng. Cụ thể ở mọi nơi mà nó không ảnh hưởng đến ý nghĩa của mã. Ngay cả trong Python nơi khoảng trắng có liên quan, nó vẫn linh hoạt khi bạn nằm trong danh sách hoặc khai báo từ điển.

Tôi chắc chắn đồng ý rằng nếu một cái gì đó có thể được giải thích theo nhiều cách hoặc nếu nó không rõ ràng 100% thì có nghĩa là quá nhiều sự mạnh mẽ có thể trở thành một nỗi đau, nhưng vẫn còn nhiều chỗ cho sự mạnh mẽ mà không mơ hồ.

Chắc chắn không phải. Các kỹ thuật như lập trình phòng thủ che khuất các lỗi, làm cho sự xuất hiện của chúng ít có khả năng và ngẫu nhiên hơn khiến cho việc phát hiện chúng trở nên khó khăn hơn khiến việc cách ly chúng trở nên khó khăn hơn.

Bộ luật Viết mã được đánh giá thấp được đánh giá rất cao trong việc liên tục nhấn mạnh đến sự cần thiết và kỹ thuật của việc tạo ra các lỗi khó giới thiệu hoặc che giấu. Thông qua việc áp dụng các nguyên tắc của nó, chẳng hạn như "Loại bỏ hành vi ngẫu nhiên. Buộc các lỗi có thể tái tạo." và "Luôn luôn tìm kiếm và loại bỏ các lỗ hổng trong giao diện của bạn." các nhà phát triển sẽ cải thiện đáng kể chất lượng phần mềm của họ bằng cách loại bỏ sự mơ hồ và các tác dụng phụ không được kiểm soát chịu trách nhiệm cho một số lượng lớn lỗi.

Việc áp dụng quá mức tính mạnh mẽ dẫn đến việc bạn đoán người dùng muốn gì, điều đó sẽ ổn cho đến khi bạn hiểu sai. Điều này cũng đòi hỏi niềm tin hoàn toàn sai lầm rằng khách hàng của bạn sẽ không lạm dụng lòng tin của bạn và tạo ra sự vô nghĩa ngẫu nhiên xảy ra, nhưng bạn sẽ không thể hỗ trợ trong phiên bản 2.

Việc áp dụng đúng mức dẫn đến việc bạn từ chối khách hàng của mình quyền mắc lỗi nhỏ, điều này sẽ ổn cho đến khi họ phàn nàn rằng công cụ của họ hoạt động tốt trên sản phẩm của đối thủ cạnh tranh và cho bạn biết bạn có thể làm gì với tiêu chuẩn 5.000 trang của bạn có chữ "DRAFT" vẫn được viết nguệch ngoạc trên trang bìa bằng bút chì và ít nhất 3 chuyên gia khẳng định là thiếu sót cơ bản và 200 chuyên gia trung thực hơn nói rằng họ không hiểu đầy đủ.

Giải pháp cá nhân của tôi luôn bị phản đối. Bạn ủng hộ họ, nhưng nói với họ rằng họ đang làm sai và (nếu có thể) là con đường dễ nhất để sửa sai. Bằng cách đó, khi bạn tắt tính năng lỗi 10 năm, bạn ít nhất có dấu vết giấy để nói rằng "chúng tôi đã cảnh báo bạn điều này có thể xảy ra."

Thật không may, cái gọi là "nguyên tắc mạnh mẽ" không dẫn đến sự mạnh mẽ. Lấy HTML làm ví dụ. Nhiều rắc rối, nước mắt, lãng phí thời gian và năng lượng có thể tránh được nếu các trình duyệt đã phân tích nghiêm ngặt HTML ngay từ đầu thay vì cố gắng đoán ý nghĩa của nội dung không đúng định dạng.

Trình duyệt chỉ đơn giản là đã hiển thị một thông báo lỗi thay vì cố gắng sửa nó dưới nắp. Điều đó sẽ buộc tất cả các nhà xây dựng phải sửa chữa mớ hỗn độn của họ.

Tôi chia giao diện thành nhiều nhóm (thêm nhiều hơn nếu bạn muốn):

1. những người nằm dưới sự kiểm soát của bạn nên nghiêm ngặt (điển hình là các lớp học)
2. API thư viện, cũng nên ở khía cạnh nghiêm ngặt, nhưng nên xác thực thêm
3. giao diện công cộng phải xử lý mọi loại lạm dụng đi kèm (thường là giao thức, đầu vào của người dùng, v.v.). Ở đây, sự mạnh mẽ về đầu vào thực sự được đền đáp, bạn không thể hy vọng mọi người sẽ sửa chữa công cụ của họ. Và hãy nhớ cho người dùng, đó sẽ là lỗi của bạn nếu ứng dụng không hoạt động, không phải bên gửi một số tin tào lao không đúng định dạng.

Đầu ra phải luôn nghiêm ngặt.

Tôi nghĩ rằng HTML và World Wide Web đã cung cấp một thử nghiệm trên thế giới thực rộng rãi về Nguyên tắc Mạnh mẽ và cho thấy nó là một thất bại lớn. Nó trực tiếp chịu trách nhiệm về sự lộn xộn của các tiêu chuẩn gần như HTML cạnh tranh khiến cuộc sống của các nhà phát triển Web (và người dùng của họ) trở nên tồi tệ hơn và trở nên tồi tệ hơn với mỗi bản phát hành Internet Explorer mới.

Chúng tôi đã biết từ những năm 1950 làm thế nào để xác nhận mã đúng. Chạy nó thông qua một trình phân tích cú pháp nghiêm ngặt và nếu một cái gì đó không đúng về mặt cú pháp, hãy đưa ra một lỗi và hủy bỏ. Đừng vượt qua, đừng thu 200 đô la, và vì tình yêu của tất cả những gì là nhị phân, đừng để một số chương trình máy tính cố gắng đọc được suy nghĩ của người viết mã nếu anh ta mắc lỗi!

HTML và JavaScript đã cho chúng ta thấy chính xác những gì xảy ra khi những nguyên tắc đó bị bỏ qua. Khóa học hành động tốt nhất là học hỏi từ những sai lầm của họ và không lặp lại chúng.

Để đối chiếu với ví dụ của Mason, kinh nghiệm của tôi với Giao thức khởi tạo phiên là trong khi các ngăn xếp khác nhau sẽ diễn giải các RFC có liên quan khác nhau (và tôi nghi ngờ điều này xảy ra với mọi tiêu chuẩn từng được viết), tự do (vừa phải) trong những gì bạn chấp nhận có nghĩa là bạn thực sự có thể thực hiện cuộc gọi giữa hai thiết bị. Vì các thiết bị này là những thứ vật lý thông thường trái ngược với các phần mềm trên máy tính để bàn, bạn chỉ cần tự do trong những gì bạn chấp nhận hoặc điện thoại của bạn không thể gọi một điện thoại khác của một sản phẩm cụ thể. Điều đó không làm cho điện thoại của bạn trông tốt!

Nhưng nếu bạn đang viết thư viện, có lẽ bạn không gặp phải vấn đề nhiều bên giải thích một tiêu chuẩn chung theo những cách không tương thích lẫn nhau. Trong trường hợp đó, tôi sẽ nói nghiêm khắc với những gì bạn chấp nhận, bởi vì nó loại bỏ sự mơ hồ.

Tệp Jargon cũng có một câu chuyện kinh dị về "đoán" ý định của người dùng.

Bạn nói đúng, quy tắc áp dụng cho các giao thức chứ không phải lập trình. Nếu bạn mắc lỗi đánh máy trong khi lập trình, bạn sẽ gặp lỗi ngay khi biên dịch (hoặc chạy, nếu bạn là một trong những kiểu động đó). Không có gì đạt được bằng cách để máy tính đoán cho bạn. Không giống như dân gian thông thường, chúng tôi là những kỹ sư và có khả năng nói chính xác ý tôi. ;)

Vì vậy, khi thiết kế API, tôi sẽ nói đừng tuân theo Nguyên tắc Mạnh mẽ. Nếu nhà phát triển mắc lỗi, họ nên tìm hiểu về nó ngay lập tức. Tất nhiên, nếu API của bạn sử dụng dữ liệu từ nguồn bên ngoài, như tệp, bạn nên khoan dung. Người dùng thư viện của bạn nên tìm hiểu về sai lầm của chính họ, nhưng không phải của ai khác.

Ở một khía cạnh khác, tôi đoán rằng "thất bại thầm lặng" được cho phép trong giao thức TCP bởi vì nếu không, nếu mọi người ném các gói không đúng định dạng vào bạn, bạn sẽ bị bắn phá với các thông báo lỗi. Đó là bảo vệ DoS đơn giản ngay tại đó.

IMO, sự mạnh mẽ là một mặt của sự đánh đổi trong thiết kế không phải là nguyên tắc "thích". Như nhiều người đã chỉ ra, không có gì hôi thối như thổi bốn tiếng đồng hồ khi cố gắng tìm ra lỗi JS của bạn chỉ để phát hiện ra vấn đề thực sự là chỉ có một trình duyệt đã làm điều đúng đắn với XHTML Strict. Nó cho phép trang thành từng mảnh khi một phần của HTML được phục vụ là một thảm họa hoàn chỉnh.

Mặt khác, ai muốn tra cứu tài liệu cho một phương thức có 20 đối số và khẳng định chúng theo thứ tự chính xác với các chủ sở hữu vị trí trống hoặc giá trị null cho những phương thức bạn muốn bỏ qua? Cách mạnh mẽ không kém phần mạnh mẽ để đối phó với phương pháp đó là kiểm tra mọi đối số và cố gắng đoán xem cái nào phù hợp với vị trí và loại tương đối và sau đó thất bại trong âm thầm hoặc cố gắng "thực hiện" với các đối số vô nghĩa.

Hoặc bạn có thể nướng linh hoạt vào quy trình bằng cách chuyển một danh sách cặp đối tượng theo nghĩa đen / từ điển / khóa-giá trị và xử lý sự tồn tại của mỗi đối số khi bạn nhận được nó. Đối với sự đánh đổi hoàn hảo rất nhỏ, đó là một chiếc bánh và ăn nó quá kịch bản.

Quá tải lập luận theo những cách thông minh và phù hợp với giao diện là một cách thông minh để mạnh mẽ về mọi thứ. Vì vậy, việc nướng dự phòng vào một hệ thống mà việc phân phối gói giả định sẽ thường xuyên không được phân phối trong một mạng lưới phức tạp ồ ạt do mọi người sở hữu và điều hành trong một lĩnh vực công nghệ mới nổi với nhiều phương tiện tiềm năng để truyền tải.

Tuy nhiên, việc chấp nhận thất bại, đặc biệt là trong một hệ thống mà bạn kiểm soát, không bao giờ là một sự đánh đổi tốt. Ví dụ, tôi đã phải hít thở để tránh ném một sự phù hợp rít lên trong một câu hỏi khác về việc đặt JS ở đầu hoặc cuối trang. Một số người khăng khăng rằng tốt hơn hết là đặt JS lên hàng đầu vì sau đó nếu trang không tải hoàn toàn, bạn vẫn có khả năng có một số chức năng. Các trang nửa làm việc tồi tệ hơn các trang hoàn chỉnh. Tốt nhất, họ dẫn đến nhiều khách truy cập vào trang web của bạn một cách đúng đắn khi cho rằng bạn không đủ năng lực trước khi bạn phát hiện ra điều đó hơn là nếu trang bị lỗi chỉ bị trả về một trang lỗi khi không kiểm tra xác thực của chính nó, sau đó là một email tự động đến ai đó có thể làm một cái gì đó về nó.

Cố gắng cung cấp chức năng 2010 trên trình duyệt 1999 khi bạn chỉ có thể cung cấp trang công nghệ thấp hơn là một ví dụ khác về sự đánh đổi thiết kế ngu ngốc. Các cơ hội đã thổi bay và tiền bạc mà tôi thấy đã lãng phí thời gian của nhà phát triển dành cho các giải pháp khắc phục lỗi chỉ để có được các góc tròn trên một phần tử lơ lửng phía trên một nền tảng độ dốc! @ # $ Ing, đã hoàn toàn thổi bay tôi. Và để làm gì? Để cung cấp các trang công nghệ cao hơn hoạt động kém cho các công nghệ đã được chứng minh đồng thời hạn chế các lựa chọn của bạn trên các trình duyệt cao cấp hơn.

Để nó là lựa chọn đúng đắn, lựa chọn xử lý đầu vào một cách mạnh mẽ sẽ luôn giúp cuộc sống dễ dàng hơn ở cả hai phía của vấn đề, trong IMO ngắn hạn và dài hạn.

Không bao giờ thất bại âm thầm . Ngoài ra, cố gắng đoán xem người dùng API / thư viện muốn gì, nghe có vẻ không phải là một ý tưởng tồi. Tôi sẽ không làm theo nó mặc dù; có một yêu cầu nghiêm ngặt, có thể làm lộ ra các lỗi trong mã gọi và / hoặc giải thích sai về API / thư viện của bạn.

Hơn nữa, như đã được chỉ ra, nó phụ thuộc vào mức độ khó để thực sự đoán những gì người dùng mong đợi. Nếu nó rất dễ, thì bạn có hai trường hợp:

1. Thư viện của bạn nên được thiết kế khác một chút (đổi tên một số chức năng hoặc chia thành hai phần), để người dùng có thể mong đợi những gì bạn thực sự cung cấp.
2. Nếu bạn tin rằng thư viện của bạn được thiết kế đúng, có nghĩa là đặt tên rõ ràng / đơn giản, thì bạn có thể thử suy luận những gì người dùng dự định.

Trong mọi trường hợp không rõ ràng và có tính xác định 100%, một đầu vào nên được chuyển đổi sang đầu vào khác, bạn không nên thực hiện chuyển đổi, vì một số lý do đã được đề cập (phá vỡ tính tương thích về tái cấu trúc, gây ngạc nhiên cho người dùng).

Khi giao dịch với người dùng cuối, cố gắng sửa lỗi nhập / đoán của họ là rất đáng hoan nghênh. Anh ta dự kiến ​​sẽ nhập thông tin không hợp lệ; trường hợp này là hoàn toàn không ngoại lệ. Một nhà phát triển khác, mặc dù, không phải là một người dùng phi kỹ thuật đơn giản. Anh ta có chuyên môn để hiểu một lỗi, và lỗi có thể có ý nghĩa / có lợi cho anh ta. Do đó, tôi đồng ý với bạn về việc thiết kế các API nghiêm ngặt, trong khi - tất nhiên sự nghiêm ngặt đi kèm với sự rõ ràng và đơn giản.

Tôi muốn đề nghị bạn đọc câu hỏi này của tôi , về một trường hợp tương tự.