Tôi có nên mặc định môi trường cho ai đó đang sử dụng thư viện của mình không?

Question

Tôi đã có cuộc tranh luận này với một người bạn, nơi tôi có một thư viện (trăn của nó nhưng tôi không bao gồm đó là một thẻ như câu hỏi được áp dụng cho bất kỳ ngôn ngữ nào) có một vài phụ thuộc. Cuộc tranh luận là liệu có nên cung cấp một môi trường mặc định trong khởi tạo hay buộc người dùng mã phải đặt một cách rõ ràng.

Ý kiến ​​của tôi là buộc người dùng đó rõ ràng và sẽ tránh nhầm lẫn và làm rõ điều họ đang trỏ đến.

Bạn tôi này an toàn hơn và thuận tiện hơn để mặc định cho môi trường và cho phép người dùng ghi đè nếu muốn.

Suy nghĩ? Có bất kỳ tài liệu tham khảo hoặc ví dụ/mẫu tốt nào trong các thư viện phổ biến hỗ trợ một trong các đối số của chúng tôi không? Ngoài ra, bất kỳ blog hoặc bài viết phổ biến nào thảo luận về điểm thiết kế API này?

Answer 1

Tôi không có bất kỳ tham chiếu nào, nhưng đây là suy nghĩ của tôi với tư cách là người dùng tiềm năng của thư viện đã nói.

Tôi nghĩ rằng nên có một cấu hình mặc định có sẵn để cho phép nhà phát triển đánh giá nhanh thư viện. Tôi không muốn phải đi qua một loạt các cấu hình chỉ để xem nếu thư viện sẽ làm những gì tôi cần. Một khi tôi hài lòng rằng thư viện sẽ làm những gì tôi cần nó để làm, sau đó tôi hạnh phúc để cấu hình nó theo cách tôi muốn.

Một ví dụ điển hình là khung công tác ASP.Net MVC của Microsoft. Khi bạn tạo một dự án MVC mới, nó móc trong một nhà cung cấp xác thực và thành viên mặc định, cho phép nhà phát triển nhanh chóng có được một ứng dụng hoạt động và chạy. Nó cũng dễ dàng để cấu hình các nhà cung cấp khác nhau được sử dụng nếu người mặc định không đáp ứng các yêu cầu của ứng dụng được đề cập.

Như một ví dụ hơi khác, Atlassian Confluence là phần mềm wiki hỗ trợ nhiều cơ sở dữ liệu back-end khác nhau. Atlassian có thể đã chọn không có cấu hình DB mặc định, nhưng thay vào đó Confluence sẽ có một cơ sở dữ liệu dựa trên tệp đơn giản, mặc định để cho phép người dùng đánh giá phần mềm. Đối với các cài đặt sản xuất, bạn có thể kết nối với Oracle, SQL Server, mySQL hoặc bất kỳ thứ gì bạn thích.

Có thể có trường hợp cấu hình mặc định cho thư viện không thực sự hợp lý, nhưng tôi nghĩ đó sẽ là trường hợp đặc biệt, thay vì quy tắc chung.

Answer 2

Điều đó tùy thuộc. Nếu bạn có thể cung cấp mặc định hợp lý, bạn có thể muốn làm điều đó: nó sẽ làm cho cuộc sống dễ dàng hơn đối với người dùng thường xuyên của thư viện vì họ chỉ có thể đặt các cài đặt có liên quan, trái ngược với toàn bộ môi trường. không hoàn toàn hiểu (chưa)). Bạn chính xác, trong trường hợp có thể dẫn đến thất vọng và nhầm lẫn vì cài đặt mặc định có thể gây ra hành vi bất ngờ (không mong muốn bởi người dùng thiếu kinh nghiệm) - bạn phải cân nhắc sự thất vọng giảm của sự tiện lợi so với giá không mặc định được hiểu để thực hiện lựa chọn cho từng cài đặt có thể mặc định này, lựa chọn nào có thể ảnh hưởng đến lựa chọn cho các cài đặt khác có liên quan cũng như

Mặt khác, nếu không có mặc định hợp lý (ví dụ: thông tin đăng nhập DB, địa chỉ từ xa), bạn nên yêu cầu người dùng cung cấp các cài đặt đó.

Chìa khóa trong cả hai trường hợp là cung cấp đủ thông tin trong tài liệu của thư viện và trong các thông báo lỗi đọc qua mã nguồn của thư viện.Phần này rất khó bởi vì 1) nó tẻ nhạt từ quan điểm của nhà phát triển thư viện (vì vậy nó thường được skimped) và 2) tài liệu phải được viết từ tư duy của một newbie đến thư viện, mà thường khác từ tư duy của nhà phát triển thư viện - người thứ hai biết các kết nối ngầm/ngụ ý, trước đây phải được nói về những người đó theo một cách dễ hiểu.

Answer 3

Mặc dù không chính xác giống nhau về miền vấn đề, điều này đánh tôi là đối số Convention over Configuration.

Đã có khá nhiều động lực đằng sau CoC trong những năm gần đây, và trong tâm trí của tôi, nó tạo nên rất nhiều ý nghĩa. Miễn là tính linh hoạt không bị mất, bạn có mọi thứ để đạt được. Phát triển ma sát thấp hơn là những gì chúng tôi là tất cả sau, và nếu tôi đã phải cấu hình mọi khía cạnh của API của bạn để có được nó làm việc, tôi ít nghiêng để sử dụng nó trên một API chức năng bình đẳng.

Tôi tình cờ thích các podcast của Hanselman, vì vậy nếu bạn muốn nghe một chút ánh sáng, hãy xem this podcast.

Answer 4

Tôi nghĩ câu hỏi của bạn cần được giải thích rõ ràng. Để bắt đầu, tôi không nghĩ rằng một thư viện nên có bất kỳ cấu hình thời gian chạy nào. Về phụ thuộc, phụ thuộc thư viện cần được xử lý theo cách phù hợp với môi trường mà chúng đang được viết. Trong python, những phụ thuộc này phải nằm trong tệp setup.py (theo yêu cầu) và cuối cùng tệp đó sẽ đáp ứng các yêu cầu của bất kỳ dịch vụ nào bạn định cung cấp cho nó (tức là pypi cho python).

Đối với các ứng dụng, hoàn toàn có thể yêu cầu cấu hình thời gian chạy, nhưng bạn nên cố gắng có các giá trị mặc định hợp lý. Nếu ứng dụng của bạn phụ thuộc vào thư viện, sự phụ thuộc đó phải được xử lý giống như cách phụ thuộc thư viện sẽ được xử lý, mặc dù thông tin đó có thể không cần thiết trong ngữ cảnh của trình cài đặt (nếu cần). Đối với hầu hết các phần kịch bản đầu tiên chạy và ilk của họ nên được ngoài của trình cài đặt/rpm.

Đối với khung web, ứng dụng của bạn sẽ mang theo cấu hình, và có khả năng nó sẽ cần được cài đặt theo cách khác với các ứng dụng truyền thống. Ở đây, về điều duy nhất bạn có thể làm là cố gắng tuân theo các quy ước của bất kỳ khung công tác nào bạn đang viết.