我一直有一個朋友，我有一個庫（它的Python，但我沒有把它作爲一個標籤，因爲這個問題適用於任何語言）有一些依賴關係的辯論。爭論的是在初始化中提供默認環境還是強制代碼的用戶明確設置一個。我應該使用我的圖書館爲某人默認環境嗎？
我的意見是強制用戶明確，避免混淆，並說明他們指的是什麼。
我的朋友這是更安全，更方便的默認環境，並讓用戶覆蓋，如果他想。
想法？流行的庫中是否有任何好的參考或例子/模式支持我們的論點？還有，討論這個API設計要點的任何流行的博客或文章？
我沒有任何參考，但這裏是我作爲該圖書館的潛在用戶的想法。
我認爲最好有一個默認配置可供開發人員快速評估庫。我不想通過一堆配置來查看庫是否能夠滿足我的需求。一旦我很高興圖書館會做我想做的事情，那麼我很樂意按照自己想要的方式進行配置。
一個很好的例子是微軟的ASP.Net MVC框架。當您創建一個新的MVC項目時，它會掛載默認的身份驗證和成員資格提供程序，從而使開發人員能夠快速啓動並運行正常運行的應用程序。如果默認的提供商不符合相關應用的要求，那麼配置不同的提供商也很容易。
作爲一個稍微不同的例子，Atlassian Confluence是支持許多不同後端數據庫的wiki軟件。 Atlassian本可以選擇沒有默認的數據庫配置，但是相反，Confluence提供了一個默認的，簡單的基於文件的數據庫，以允許用戶評估軟件。對於生產安裝，您可以連接到Oracle，SQL Server，mySQL或其他任何你喜歡的東西。
有些情況下，圖書館的默認配置文件沒有意義，但我認爲這將是一個特例，而不是一般規則。
這取決於。如果您可以提供合理的默認設置，您可能需要這樣做：它會讓圖書館的偶爾用戶生活更加複雜，因爲他們只能設置相關設置，而不是整個環境（可能會設置它們的影響不完全理解（還））。你是對的，在這種情況下，這可能會導致沮喪和困惑，因爲默認設置可能會導致意外的行爲（用戶（沒有經驗）的用戶意想不到） - 你必須權衡減少的便利性與未付費的價格之間的沮喪，瞭解默認設置，以便爲這些可能的默認設置中的每一個做出選擇，哪個選項可能會影響其他相關設置的選擇
另一方面，如果沒有合理的默認設置（例如DB憑據，遠程地址），您應該要求用戶提供這些設置。
這兩種情況下的關鍵是在庫的文檔和錯誤消息（無論是缺少設置還是相互衝突）中提供足夠的信息，以便用戶可以弄清楚這些設置實際上意味着什麼，而無需閱讀庫的源代碼。這一部分很難，因爲1）從圖書館開發人員的角度來看，這是非常乏味的（所以經常被忽略）和2）文檔必須從新手的心態寫入圖書館，這通常是不同的從圖書館開發人員的想法 - 後者知道隱含的聯繫/含義，前者必須以可理解的方式告訴他們。
雖然在問題域方面並不完全相同，但這引起我作爲Convention over Configuration參數。
近年來，CoC背後的發展勢頭很猛，在我看來，它有很多意義。只要靈活性不會丟失，你就能獲得一切。降低摩擦的發展是我們所有人的事情，如果我必須配置API的各個方面才能使其發揮作用，那麼我不太傾向於將它用於具有相同功能的其他API。
我碰巧喜歡Hanselman的播客，所以如果你想要一點點聆聽，請查看this podcast。
我認爲你的問題需要一些澄清。對於初學者，我不認爲庫應該有任何運行時配置。就依賴性而言，應該以適合其編寫環境的方式來處理庫依賴性。在python中，這些依賴關係應該在setup.py文件中（根據需求），並且最終該文件應該滿足您計劃使其可用的所有服務（即python的pypi）的要求。
對於應用程序來說，要求運行時配置是完全可以的，但您應該嘗試設置合理的默認值。如果您的應用程序依賴於庫，那麼即使該信息在安裝程序的上下文中可能是多餘的（如果需要），也應按照處理庫依賴性的方式處理該依賴性。大多數情況下，第一次運行的腳本和它們的流派應該是安裝程序/ rpm的一部分。
對於Web框架，通常應用程序會攜帶配置，並且可能需要以與傳統應用程序不同的方式進行安裝。在這裏，你可以做的唯一事情就是儘量遵循你正在編寫的任何框架的約定。
類似的思考http://stackoverflow.com/questions/1166539/do-you-find-convention-over -configuration-good-or-bad – mguymon 2012-03-17 07:46:06
@mguymon - 我認爲它是一個稍微不同的話題。 – leora 2012-03-17 12:46:14
目標受衆是另一個需要考慮的重要因素。一個公司內部對網絡上的任何人是內部的東西嗎？對於有設計師思維和工程思維的用戶？等等。 – 2012-05-03 16:07:31