在軟件開發(fā)中，我們常常為溝通效率低下而頭疼。
接手維護(hù)項(xiàng)目時，面對低質(zhì)量代碼，不得不一次又一次地與前任開發(fā)者溝通；
團(tuán)隊(duì)內(nèi)部，模塊分散，編程風(fēng)格各異，使用對方服務(wù)時需要反復(fù)確認(rèn)；
跨團(tuán)隊(duì)合作，技術(shù)棧不同，更需要花費(fèi)大量時間統(tǒng)一標(biāo)準(zhǔn)……
這些問題的根源在于代碼本身帶來的學(xué)習(xí)成本和溝通成本。每一份代碼都像是一本需要重新學(xué)習(xí)的書籍，需要反復(fù)研究和溝通才能理解。
然而，為什么學(xué)習(xí)了 Spring 框架后，我們與他人交流相關(guān)問題時效率會顯著提高？
答案在于 Spring Boot 框架應(yīng)用了一個簡單卻強(qiáng)大的原則：慣例優(yōu)于配置（Convention over Configuration，CoC）。
這個原則幫助編程者提前建立起隱形的公共知識體系，當(dāng)一方提及某個知識點(diǎn)時，另一方早已心領(lǐng)神會，無需反復(fù)解釋，溝通效率自然水到渠成。
一、慣例原則：用“共同語言”編程
慣例原則起源于 Ruby On Rails 框架，其核心理念是將編程中公認(rèn)的配置方式和約定信息作為內(nèi)部默認(rèn)規(guī)則。例如MyBatis 的映射文件通常命名為 xxxMapper.xml。
由于是默認(rèn)統(tǒng)一的規(guī)則，大多數(shù)開發(fā)者都會優(yōu)先采用，久而久之，便對規(guī)則形成統(tǒng)一認(rèn)知，溝通時自然減少了重復(fù)理解和溝通的時間。
我們可以將慣例原則理解為一種約束，在特定框架（知識體系）下，根據(jù)這些約束制定默認(rèn)規(guī)則，框架便能基于這些規(guī)則實(shí)現(xiàn)統(tǒng)一操作。
例如，Spring 框架中，使用 @Autowired 注解自動注入 Java Bean，框架通過解析注解自動尋找對應(yīng)的 Bean。
因此，慣例原則也被稱為“按約定編程”。
與契約原則（DBC）強(qiáng)調(diào)的“按統(tǒng)一協(xié)議/標(biāo)準(zhǔn)協(xié)作”不同，慣例原則更注重隱性知識的共享。
例如，使用 Maven 管理工程結(jié)構(gòu)，其實(shí)是預(yù)設(shè)了維護(hù)者已經(jīng)了解 Maven 相關(guān)的慣例約定。
二、慣例原則解決的問題
以常見的 Maven 自動生成的 Java 工程結(jié)構(gòu)為例，這個目錄結(jié)構(gòu)對 Java 程序員來說不言自明，這就是一種公認(rèn)的慣例。
慣例原則主要解決了編程中對共同隱性知識的學(xué)習(xí)問題，通過統(tǒng)一的默認(rèn)規(guī)則，建立起溝通的橋梁。
當(dāng)然，我們可以不使用慣例，但代價是花費(fèi)大量時間解釋和說明新規(guī)則，并確保消除其他人的誤解。
除此之外，慣例原則還間接帶來了以下好處：
● 形成編程圈的專業(yè)行話
在編程領(lǐng)域，使用慣例就像使用專業(yè)術(shù)語，無需額外解釋， everyone gets it.
● 減少決策次數(shù)，降低認(rèn)知負(fù)擔(dān)
慣例幫助開發(fā)者快速做出選擇，避免在眾多技術(shù)方案中猶豫不決，從而專注于解決實(shí)際問題。
三、慣例原則的副作用
使用慣例原則能帶來良好的可維護(hù)性和溝通效率，但也要警惕其潛在的副作用：
● 靈活性降低
過于定制化的默認(rèn)規(guī)則，雖然統(tǒng)一了認(rèn)知，但也限制了靈活性。例如，統(tǒng)一使用 ApiResponseResult 類處理 JSON 返回格式，如果需要修改數(shù)據(jù)格式，可能需要改動大量代碼。
● 自定義慣例的風(fēng)險
自定義慣例需要團(tuán)隊(duì)內(nèi)部反復(fù)確認(rèn)，否則可能導(dǎo)致嚴(yán)重問題。例如，數(shù)據(jù)庫 YN 字段默認(rèn)值不統(tǒng)一，可能導(dǎo)致數(shù)據(jù)遷移時出現(xiàn)錯誤。
● 參考變強(qiáng)制
慣例原則可能演變成強(qiáng)制標(biāo)準(zhǔn)，導(dǎo)致設(shè)計僵化。例如，數(shù)據(jù)類只能寫 get、set 方法，或者代碼只寫在一個層級。
● 不同框架慣例不可復(fù)用
不同知識體系下的慣例不同，不可混淆使用。例如，C++ 和 Java 的開發(fā)慣例就存在差異。
四、如何正確使用慣例原則
為了避免慣例原則的副作用，我們需要掌握以下技巧：
● 遵循大多數(shù)人的慣例
選擇業(yè)界公認(rèn)的慣例，例如 Java 的駝峰命名、MySQL 數(shù)據(jù)庫字段的下劃線分割等，確保理解一致性，減少溝通成本。
● 明確慣例的適用范圍
不同的慣例適用于不同的編程語言、場景和行業(yè)，需要根據(jù)實(shí)際情況選擇使用。
● 自定義慣例需團(tuán)隊(duì)確認(rèn)
自定義慣例時，確保團(tuán)隊(duì)內(nèi)每個人都知曉并理解，并在實(shí)際編碼中與調(diào)用方反復(fù)確認(rèn)。
● 平衡慣例與靈活性
不要過度使用慣例，在需要靈活性的情況下，可以選擇配置或代碼實(shí)現(xiàn)。
● 避免強(qiáng)制他人使用慣例
慣例應(yīng)該是一種自由選擇，而不是強(qiáng)制要求，避免破壞他人的編程習(xí)慣，降低開發(fā)效率。
總之，慣例優(yōu)于配置原則就像軟件開發(fā)中的隱形橋梁，幫助我們跨越溝通的鴻溝，提升開發(fā)效率。
但也要警惕其潛在的副作用，靈活運(yùn)用，才能最大限度地發(fā)揮其優(yōu)勢，構(gòu)建高效、可維護(hù)的優(yōu)質(zhì)軟件。
