3.1 代碼之旅：基礎規范

在設計架構的時候，要考慮由下而上的模式，底層的實踐最終會影響整個系統的架構。再好的架構，如果沒有輔以有效的工程實踐，那么最終我們得到的只是一個空有其表的架構方案。能自下而上影響軟件架構的，就只有代碼了。

代碼本身是一種難以衡量的實踐，同一個業務功能有不同的代碼實現。想象一個場景，我們對外提供了一個RESTful API，是不是只要我們能以規范的方式提供這個RESTful API接口，代碼的實現方式和質量就變得不重要了？

從短期來看，如果一個API能快速地提供功能以驅動業務增長，那么它就是一個成功的API。不論其設計多么丑陋，代碼質量多差，只要不影響性能，未來就有改進的空間?？墒菑拈L期來看，API是要能夠面向變化而快速擴展的，如果我們不能方便地在API中擴展功能，那么它就真的會影響業務了。盡管重構舊的代碼可以幫助我們走向更好的架構，但是在業務進度不合理的情況下，我們只能在舊的、丑陋的代碼上不斷堆砌功能。直至有一天，我們愉快地選擇重寫系統。

在本節里，我們將討論代碼中的一些基礎規范，它們更多地關注代碼的可讀性，而不是代碼的質量，我們會在后面的章節里關注代碼質量。為了提升代碼的可讀性，我們需要做到以下幾方面：

◎ 規范代碼組織結構。

◎ 統一代碼風格，即源代碼的書寫風格。

◎ 組件、函數等命名規范。

◎ 開發工具規范。

光看這幾點要求，總覺得似乎多了很多條條框框。盡管這種統一性會扼殺團隊的多樣性，但是對于代碼層次的風格統一是相當有必要的。

在這些實踐中，有些并不僅僅是實踐，它還反映了架構的模式，如代碼組織結構——從代碼的組織構建上，我們可以真真切切地感受到它與系統架構的相似之處。由于應用內的代碼復用采用組件化的架構，所以我們應該隔離不同的組件。比如，在Angular生成的組件（component）中，我們就可以看到一種組件完全獨立的存在形式。