代碼之旅：基礎規範

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

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

從短時間來看，若是一個API能快速地提供功能以驅動業務增加，那麼它就就是一個成功的 API。不論其設計得多麼醜陋，代碼質量多差，只要不影響性能，將來就有改進的空間。但是從長期來看，API是要可以面向變化而快速拓展的，若是咱們不能方便地在 API 中拓展功能，那麼它就真的會影響業務了。儘管重構的代碼能夠幫助咱們走向更好的架構，可是在業務進度不合理的狀況下，咱們只能在舊的、醜陋的代碼上不斷堆砌功能。直至有一天，咱們愉快地選擇重寫系統。

在本節裏，咱們將討論代碼中的一些基礎規範，他們更多地關注代碼的可讀性，而不是代碼的質量，咱們會在後面的章節裏關注代碼質量。爲了提高代碼的可讀性，咱們須要作到如下的幾方面：

• 規範代碼組織結構
  • 統一代碼風格，即源代碼的書寫風格
  • 組件、函數等命名規範
  • 開發工具規範

光看這幾點要求，總以爲彷佛多了不少條條框框。儘管這種統一性會扼殺團隊的多樣性，可是對於代碼層次的風格統一是至關有必要的。

在這些實踐中，有些並不單單是實踐，他還反應了架構的模式，如代碼組織結構 —— 從代碼的組織構架上，咱們能夠真真切切地感覺到他與系統架構的類似之處。因爲應用內的代碼複用採用組件化的架構，因此咱們應該隔離不一樣的組件。好比，在 Angular 生成的組件 component 中，咱們就能夠看到一種組件徹底獨立的存在形式。

本文由博客一文多發平臺 OpenWrite 發佈！