程序員如何提升編程中的溝通效率？Get這些“暗號”！

在軟件開發(fā)中，我們常常為溝通效率低下而頭疼。

接手維護項目時，面對低質量代碼，不得不一次又一次地與前任開發(fā)者溝通；

團隊內部，模塊分散，編程風格各異，使用對方服務時需要反復確認；

跨團隊合作，技術棧不同，更需要花費大量時間統一標準……

這些問題的根源在于代碼本身帶來的學習成本和溝通成本。每一份代碼都像是一本需要重新學習的書籍，需要反復研究和溝通才能理解。

然而，為什么學習了 Spring 框架后，我們與他人交流相關問題時效率會顯著提高？

答案在于 Spring Boot 框架應用了一個簡單卻強大的原則：慣例優(yōu)于配置（Convention over Configuration，CoC）。

這個原則幫助編程者提前建立起隱形的公共知識體系，當一方提及某個知識點時，另一方早已心領神會，無需反復解釋，溝通效率自然水到渠成。

一、慣例原則：用“共同語言”編程

慣例原則起源于 Ruby On Rails 框架，其核心理念是將編程中公認的配置方式和約定信息作為內部默認規(guī)則。例如MyBatis 的映射文件通常命名為 xxxMapper.xml。

由于是默認統一的規(guī)則，大多數開發(fā)者都會優(yōu)先采用，久而久之，便對規(guī)則形成統一認知，溝通時自然減少了重復理解和溝通的時間。

我們可以將慣例原則理解為一種約束，在特定框架（知識體系）下，根據這些約束制定默認規(guī)則，框架便能基于這些規(guī)則實現統一操作。

例如，Spring 框架中，使用 @Autowired 注解自動注入 Java Bean，框架通過解析注解自動尋找對應的 Bean。

因此，慣例原則也被稱為“按約定編程”。

與契約原則（DBC）強調的“按統一協議/標準協作”不同，慣例原則更注重隱性知識的共享。

例如，使用 Maven 管理工程結構，其實是預設了維護者已經了解 Maven 相關的慣例約定。

二、慣例原則解決的問題

以常見的 Maven 自動生成的 Java 工程結構為例，這個目錄結構對 Java 程序員來說不言自明，這就是一種公認的慣例。

慣例原則主要解決了編程中對共同隱性知識的學習問題，通過統一的默認規(guī)則，建立起溝通的橋梁。

當然，我們可以不使用慣例，但代價是花費大量時間解釋和說明新規(guī)則，并確保消除其他人的誤解。

除此之外，慣例原則還間接帶來了以下好處：

● 形成編程圈的專業(yè)行話

在編程領域，使用慣例就像使用專業(yè)術語，無需額外解釋， everyone gets it.

● 減少決策次數，降低認知負擔

慣例幫助開發(fā)者快速做出選擇，避免在眾多技術方案中猶豫不決，從而專注于解決實際問題。

三、慣例原則的副作用

使用慣例原則能帶來良好的可維護性和溝通效率，但也要警惕其潛在的副作用：

● 靈活性降低

過于定制化的默認規(guī)則，雖然統一了認知，但也限制了靈活性。例如，統一使用 ApiResponseResult 類處理 JSON 返回格式，如果需要修改數據格式，可能需要改動大量代碼。

● 自定義慣例的風險

自定義慣例需要團隊內部反復確認，否則可能導致嚴重問題。例如，數據庫 YN 字段默認值不統一，可能導致數據遷移時出現錯誤。

● 參考變強制

慣例原則可能演變成強制標準，導致設計僵化。例如，數據類只能寫 get、set 方法，或者代碼只寫在一個層級。

● 不同框架慣例不可復用

不同知識體系下的慣例不同，不可混淆使用。例如，C++ 和 Java 的開發(fā)慣例就存在差異。

四、如何正確使用慣例原則

為了避免慣例原則的副作用，我們需要掌握以下技巧：

● 遵循大多數人的慣例

選擇業(yè)界公認的慣例，例如 Java 的駝峰命名、MySQL 數據庫字段的下劃線分割等，確保理解一致性，減少溝通成本。

● 明確慣例的適用范圍

不同的慣例適用于不同的編程語言、場景和行業(yè)，需要根據實際情況選擇使用。

● 自定義慣例需團隊確認

自定義慣例時，確保團隊內每個人都知曉并理解，并在實際編碼中與調用方反復確認。

● 平衡慣例與靈活性

不要過度使用慣例，在需要靈活性的情況下，可以選擇配置或代碼實現。

● 避免強制他人使用慣例

慣例應該是一種自由選擇，而不是強制要求，避免破壞他人的編程習慣，降低開發(fā)效率。

總之，慣例優(yōu)于配置原則就像軟件開發(fā)中的隱形橋梁，幫助我們跨越溝通的鴻溝，提升開發(fā)效率。

但也要警惕其潛在的副作用，靈活運用，才能最大限度地發(fā)揮其優(yōu)勢，構建高效、可維護的優(yōu)質軟件。