在設計架構的時候，要考慮由下而上的模式，底層的實踐最侄訓影響整個系統的架構，再好的架構，如果沒有輔以有效的工程實踐，那么最終我們得到的只是一只空有其表的架構方案，能自下而上影響軟體架構的，就只有代碼了，
代碼本身是一種難以衡量的實踐，同一個業務功能有不同的代碼實作，想象一個場景，我們對外提供了一個 RESTful API 介面，是不是只要我們能以規范的方式提供這個RESTful API 介面，代碼的實作方式和質量就變得不重要了？
從短期來看，如果一個API能快速地提供功能以驅動業務增長，那么它就就是一個成功的 API，不論其設計得多么丑陋，代碼質量多差，只要不影響性能，未來就有改進的空間，可是從長期來看，API是要能夠面向變化而快速拓展的，如果我們不能方便地在 API 中拓展功能，那么它就真的會影響業務了，盡管重構的代碼可以幫助我們走向更好的架構，但是在業務進度不合理的情況下，我們只能在舊的、丑陋的代碼上不斷堆砌功能，直至有一天，我們愉快地選擇重寫系統，
在本節里，我們將討論代碼中的一些基礎規范，他們更多地關注代碼的可讀性，而不是代碼的質量，我們會在后面的章節里關注代碼質量，為了提升代碼的可讀性，我們需要做到以下的幾方面：
- 規范代碼組織結構
- 統一代碼風格，即源代碼的書寫風格
- 組件、函式等命名規范
- 開發工具規范
光看這幾點要求，總覺得似乎多了很多條條框框，盡管這種統一性會扼殺團隊的多樣性，但是對于代碼層次的風格統一是相當有必要的，
在這些實踐中，有些并不僅僅是實踐，他還反應了架構的模式，如代碼組織結構 —— 從代碼的組織構架上，我們可以真真切切地感受到他與系統架構的相似之處，由于應用內的代碼復用采用組件化的架構，所以我們應該隔離不同的組件，比如，在 Angular 生成的組件 component 中，我們就可以看到一種組件完全獨立的存在形式，
本文由博客一文多發平臺 OpenWrite 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/5461.html
標籤：JavaScript
上一篇：JS30 - 01 JavaScript Drum Kit
下一篇：WEB前端第二十五課——js字串