在設(shè)計架構(gòu)的時候师郑，要考慮由下而上的模式消别，底層的實踐最終會影響整個系統(tǒng)的架構(gòu)。再好的架構(gòu)低淡，如果沒有輔以有效的工程實踐姓言，那么最終我們得到的只是一只空有其表的架構(gòu)方案。能自下而上影響軟件架構(gòu)的蔗蹋，就只有代碼了何荚。
代碼本身是一種難以衡量的實踐。同一個業(yè)務(wù)功能有不同的代碼實現(xiàn)猪杭。想象一個場景餐塘，我們對外提供了一個 RESTful API 接口，是不是只要我們能以規(guī)范的方式提供這個RESTful API 接口皂吮，代碼的實現(xiàn)方式和質(zhì)量就變得不重要了戒傻？
從短期來看，如果一個API能快速地提供功能以驅(qū)動業(yè)務(wù)增長涮较，那么它就就是一個成功的 API稠鼻。不論其設(shè)計得多么丑陋，代碼質(zhì)量多差狂票，只要不影響性能候齿，未來就有改進(jìn)的空間。可是從長期來看慌盯，API是要能夠面向變化而快速拓展的周霉，如果我們不能方便地在 API 中拓展功能，那么它就真的會影響業(yè)務(wù)了亚皂。盡管重構(gòu)的代碼可以幫助我們走向更好的架構(gòu)俱箱，但是在業(yè)務(wù)進(jìn)度不合理的情況下，我們只能在舊的灭必、丑陋的代碼上不斷堆砌功能狞谱。直至有一天，我們愉快地選擇重寫系統(tǒng)禁漓。
在本節(jié)里跟衅，我們將討論代碼中的一些基礎(chǔ)規(guī)范，他們更多地關(guān)注代碼的可讀性播歼，而不是代碼的質(zhì)量伶跷，我們會在后面的章節(jié)里關(guān)注代碼質(zhì)量。為了提升代碼的可讀性秘狞，我們需要做到以下的幾方面：
- 規(guī)范代碼組織結(jié)構(gòu)
- 統(tǒng)一代碼風(fēng)格叭莫，即源代碼的書寫風(fēng)格
- 組件、函數(shù)等命名規(guī)范
- 開發(fā)工具規(guī)范
光看這幾點要求烁试，總覺得似乎多了很多條條框框雇初。盡管這種統(tǒng)一性會扼殺團(tuán)隊的多樣性，但是對于代碼層次的風(fēng)格統(tǒng)一是相當(dāng)有必要的减响。
在這些實踐中抵皱，有些并不僅僅是實踐，他還反應(yīng)了架構(gòu)的模式辩蛋，如代碼組織結(jié)構(gòu) —— 從代碼的組織構(gòu)架上，我們可以真真切切地感受到他與系統(tǒng)架構(gòu)的相似之處移盆。由于應(yīng)用內(nèi)的代碼復(fù)用采用組件化的架構(gòu)悼院，所以我們應(yīng)該隔離不同的組件。比如咒循，在 Angular 生成的組件 component 中据途，我們就可以看到一種組件完全獨立的存在形式。
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布叙甸！
