如何評價“約定優於配置”的編程模式?

回複內容：

這是架構的設計理念，沒見過哪個語言是這樣的。語言的文法就可以看做是一種約定
編譯器或解譯器的參數如果能影響文法的含義或支援，就算配置。用心智空間換打字速度人都是很懶的，能既省時間又省精力幹嘛要重複做那些麻煩的事我想到了lavavel，你倒是舉個例子啊～～作為一個可悲的java開發人員，我說一下感性的東西。
多組件配合的時候，你可以去配置，100個配置點你就有寫100遍，因為你不可能知道這些配置點預設值是什麼，是否必填項。
那麼，約定就好像java的getter和setter，name屬性，它的setter必然是setName,getter必然是getName，我不需要去配置中指定，用反射直接可以拿到setName和getName。
這是一種設計理念，一個團隊中約定條件1 2 3，比如，dao的底層sql查詢用add_表示增、del_開頭表示刪除，那麼配置事務時候就直接add_* 指定一個策略就行了，這是約定。減少你出錯的可能性，這是工程層面的東西，那麼擴充到一種語言，就好像java的getter和setter，也算一種約定，但是為了語言的靈活性，這樣的約定會比較少，不像架構中約定使用的這麼隨意。就好像和熟人合作優於陌生人，但現實是殘酷的約定重於配置會造成熟的人上手很快，不熟的人學習成本上升。
約定重於配置會導致擴充性下降，為了彌補配置的不足會產生很重的實現，最終又體現在學習成本的增加上。
約定重於配置能夠讓熟手在熟悉的領域快速開發，長遠來看不一定是好事。約定大於配置，只要記住約定的，就少寫了設定檔沒見過哪個語言？go語言的函數首字母大寫表示public、小寫表示private算不算？

