按慣例編碼是否會妨礙靈活性？

Question

首先，我100％支持公約和整個團隊遵守。不過，我正在研究框架（主要是各種PHP，但也包括Ruby on Rails和其他），這幾乎可以強制按照慣例進行編碼。表面上看起來這是一件好事，例如，網址直接轉換爲/controller/action。模型以數據庫表命名，系統知道使用真正簡單的自動加載器確切地加載所有文件的位置。

但是，我們運營的是白標籤平臺，對大多數客戶而言，它並不一定適用於其他客戶。有些可能需要特定的URL模式，所以我們需要自定義路由。有些人可能會要求頁面與其他客戶端具有完全不同的佈局，因此我們最終將使用一個自動加載器來始終檢查區域特定版本的文件是否首先存在，如果需要則會回退到默認值。這使得開發對我們來說真的很容易，因爲我們只是將一個適當命名的文件放到一個地方並離開它。但是由於這是少數情況下需要這些的情況，我們發現自動加載機花費過多的時間來檢查幾乎可以保證丟失的文件。

爲了提高一點，我正在考慮增加配置在約定的情況下，使從規範偏離區會找到必要的覆蓋在配置文件中和只會直奔正確的文件，刪除所有我收集的現有文件檢查效率不高（特別是當某些頁面需要數百個自動加載器調用時）。我想我們仍然會默認使用約定，但允許配置在必要時接管。

我有興趣瞭解這是否是一個實際的，甚至推薦的解決方案

Answer 1

Rails的作品大多如此。你有約定，但所有東西都帶有可選的參數，可以根據需要改變它們。有一個遺留的數據庫，其中唯一的ID是不是被命名爲id，正如Rails所期望的那樣？只要告訴Rails這個名字。你的路線是不同的？你仍然可以編寫你自己的匹配器。記錄保存之前有什麼需要完成的嗎？只需掛入before_save即可。

對於其他所有事情的工作。你有更多的工作來聲明所有不同的東西，但是你必須爲此寫一些代碼。

我們在一個稍微不常見的環境中使用Rails，我們需要使用來自ERP系統的數據並使用其他未與Rails完全集成的系統，但它在內核中仍需要大量工作。

但是，顯然它只有在所有系統具有足夠大的核心內容時纔有意義，特別是如果您打算從頭開始完全編寫某些內容。增加靈活性並不是所有事情都需要經過仔細的規劃。

Answer 2

在我們的應用程序中，我們使用兩種配置AND約定，但配置比後者稍多一些（在一些地區，反過來），這是因爲你幾乎總是會遇到你的約定不會滿足你真實世界的要求。

如果是這種情況，您的約定不適合您的架構和客戶，或者您的使用案例太多，因此約定的使用情況一致且可靠。

您可以改進您的約定以適應您的應用程序要求，但我認爲在您的組合中添加一些配置可能會帶來一些您可能缺乏的順序。我喜歡約定的是，它在某些情況下類似於魔術......但是，在一個純粹的約定的合理大小的開發環境中工作會很困難。

你的想法很實用，我甚至會推薦它，如果鞋子合適的話。

Answer 3

「程序必須供人閱讀的機器來執行寫的，只是偶然。」

- 哈爾阿伯爾森，計算機程序的結構與解釋

你可能不喜歡什麼我即將說，但有時性能不是問題。我會堅持讓開發人員開心的解決方案。如果遵循一個簡單的約定，那麼最好堅持下去，而不是創建一個複雜的配置機制。這裏沒有銀彈，但在我看來，你將簡單地用另一個（將這些配置放在這裏，而這些 - 這裏是）替換一個約定（這裏和那個地方）。它會更難以遵循？大概。它在你的手中，使它易於使用。

而且，一如既往，讓你的同事們開心。或者他們會找到你。並吃掉你。並用討厭的評論覆蓋你的代碼（這是最糟糕的部分）。