1.?行為準(zhǔn)則

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-760153.html

2.?需求的不確定性

2.1.?不斷變化的客戶需求

2.2.?軟件項(xiàng)目無(wú)法避免的挑戰(zhàn)

2.3.?產(chǎn)品需求和環(huán)境會(huì)隨著時(shí)間的推移而改變，你的應(yīng)用程序也必須隨之改變

2.4.?不斷變化的需求會(huì)導(dǎo)致不穩(wěn)定性，使開(kāi)發(fā)工作偏離軌道

2.5.?通過(guò)構(gòu)建可演進(jìn)的架構(gòu)來(lái)適應(yīng)不斷變化的需求

2.5.1.?可演進(jìn)的架構(gòu)可避免復(fù)雜性，復(fù)雜性是演進(jìn)性的敵人

2.5.2.?矛盾的是，在軟件中實(shí)現(xiàn)簡(jiǎn)潔性會(huì)很困難

3.?復(fù)雜性

3.1.?復(fù)雜系統(tǒng)的特點(diǎn)

3.1.1.?高依賴性

3.1.1.1.?致軟件依賴于其他的API或代碼行為

3.1.1.2.?依賴性顯然不可避免，甚至是可取的，但必須取得平衡

3.1.1.3.?高依賴性的系統(tǒng)很難修改

3.1.1.3.1.?它們有緊密的耦合性和高度的變更放大效應(yīng)

3.1.1.3.2.?緊密的耦合性是指那些嚴(yán)重依賴彼此的模塊，它們導(dǎo)致了更高的變更放大的倍率，即某項(xiàng)單一的變更也需要修改依賴關(guān)系

3.1.1.4.?深思熟慮的API設(shè)計(jì)和有節(jié)制地使用抽象模型將最大限度地降低緊耦合性和變更放大效應(yīng)

3.1.2.?高隱蔽性

3.1.2.1.?使得程序員很難預(yù)測(cè)某項(xiàng)變更的副作用、代碼的行為方式，以及需要修改的地方

3.1.2.2.?晦澀的代碼需要更長(zhǎng)的時(shí)間來(lái)學(xué)習(xí)，開(kāi)發(fā)人員更有可能在無(wú)意中破壞某些東西

3.1.2.3.?癥狀

3.1.2.3.1.?“知道”太多的對(duì)象

3.1.2.3.2.?鼓勵(lì)副作用的全局狀態(tài)

3.1.2.3.3.?掩蓋代碼的過(guò)度間接尋址

3.1.2.3.4.?影響程序遠(yuǎn)程行為的遠(yuǎn)距離操作

3.1.2.4.?采用具有明確的約定和標(biāo)準(zhǔn)模式的API可以減少隱蔽性

3.1.3.?高慣性

3.1.3.1.?指軟件保持之前的使用習(xí)慣

3.1.3.2.?用于快速實(shí)驗(yàn)且很容易被丟棄的代碼具有低慣性

3.1.3.3.?一項(xiàng)為十幾個(gè)關(guān)鍵業(yè)務(wù)應(yīng)用提供驅(qū)動(dòng)力的服務(wù)具有高慣性

3.1.3.4.?復(fù)雜性的成本隨著時(shí)間的推移而增加，所以高慣性、高變化的系統(tǒng)應(yīng)該被簡(jiǎn)化，而低慣性或低變化的系統(tǒng)可以保持復(fù)雜（只要你拋棄它們或繼續(xù)讓它們保持不變）

3.2.?復(fù)雜性不總能被消除，但你可以選擇把它放在哪里

3.2.1.?向后兼容的變更可能使代碼使用起來(lái)更簡(jiǎn)單，實(shí)現(xiàn)起來(lái)卻更復(fù)雜

3.2.2.?用于解耦子系統(tǒng)的間接層可降低依賴性，卻會(huì)提高隱蔽性

4.?可演進(jìn)的設(shè)計(jì)

4.1.?面對(duì)未來(lái)未知的需求策略

4.1.1.?試圖預(yù)判未來(lái)的需求

4.1.2.?建立抽象模型作為逃生艙門(mén)，使后續(xù)的代碼修改更容易

4.1.3.?都會(huì)導(dǎo)致復(fù)雜性提高

4.2.?KISS的原則

4.2.1.?要保持事情簡(jiǎn)單一些

4.2.2.?使用KISS記憶法，記住要以簡(jiǎn)單性為核心原則構(gòu)建系統(tǒng)

4.2.3.?簡(jiǎn)單的代碼可以讓你在未來(lái)增加系統(tǒng)的復(fù)雜性

4.3.?保持代碼簡(jiǎn)單的最簡(jiǎn)單的方法之一是避免什么代碼都要寫(xiě)出來(lái)

4.3.1.?告訴你自己，你不是真的需要(You ain’t gonna need it，YAGNI)

4.3.2.?要使用最小驚訝原則和封裝原則

4.4.?不要構(gòu)建你不需要的東西

4.4.1.?靠猜測(cè)而編寫(xiě)出來(lái)的代碼會(huì)繼續(xù)使事情陷入困境，它需要被維護(hù)，開(kāi)發(fā)人員需要理解它，它必須被構(gòu)建和測(cè)試

4.4.2.?避免過(guò)早優(yōu)化，避免不必要的靈活抽象模型，以及避免最小可行產(chǎn)品(minimum viable product，MVP)所不需要的產(chǎn)品特性

4.4.3.?過(guò)早優(yōu)化是指開(kāi)發(fā)人員在證明需要優(yōu)化之前就對(duì)代碼進(jìn)行性能優(yōu)化

4.4.4.?靈活的抽象模型——插件式架構(gòu)、封裝接口和通用數(shù)據(jù)結(jié)構(gòu)（如鍵值對(duì)）是另一種誘惑

4.4.4.1.?抽象自有代價(jià)：它把實(shí)現(xiàn)的代碼框在僵硬的邊界里，而開(kāi)發(fā)者最終會(huì)與之抗?fàn)?/h4>

4.4.4.2.?靈活性也使代碼更難以閱讀和理解

4.4.4.2.1.?保持代碼靈活性的最佳方法之一是減少代碼的總量

4.4.4.2.2.?蒙茨法(muntzing)，將使你的軟件保持“苗條”和適應(yīng)性

4.4.5.?MVP允許你先測(cè)試一個(gè)想法，而不必押寶在某項(xiàng)成熟的實(shí)施上

4.4.5.1.?在你懷疑可以插入優(yōu)化的地方放置接口填充程序，但不要真正實(shí)現(xiàn)它們

4.5.?最小驚訝原則

4.5.1.?不要讓用戶感到驚訝，構(gòu)建特性表現(xiàn)得要像用戶最初期望的那樣，具有上揚(yáng)的學(xué)習(xí)曲線或奇怪表現(xiàn)的特性會(huì)使用戶感到沮喪

4.5.2.?不要讓開(kāi)發(fā)者感到驚訝，令人驚訝的代碼通?；逎y懂，這會(huì)導(dǎo)致復(fù)雜性

4.5.3.?通過(guò)保持代碼的針對(duì)性、避免隱性知識(shí)，以及使用標(biāo)準(zhǔn)類庫(kù)和模式來(lái)消除驚訝

4.5.4.?凡是開(kāi)發(fā)者在調(diào)用API時(shí)需要知道的但又不屬于API本身的不明顯的知識(shí)，都被視為隱性知識(shí)

4.5.5.?排序需求決定了某些動(dòng)作必須按照某種特定的順序進(jìn)行

4.5.5.1.?使用文檔來(lái)說(shuō)明某些排序需求是種好辦法，但最好是一開(kāi)始就沒(méi)有這個(gè)排序需求

4.5.6.?當(dāng)一個(gè)方法的簽名暗示了比該方法實(shí)際可以接受的有效輸入范圍更廣時(shí)，就會(huì)出現(xiàn)隱藏的參數(shù)需求

4.5.7.?切記讓參數(shù)需求具體化和可視化

4.5.7.1.?使用可準(zhǔn)確適配約束的特定類型，當(dāng)使用靈活的類型如JSON時(shí)，考慮使用JSON schema來(lái)描述預(yù)期的對(duì)象

4.5.8.?使用標(biāo)準(zhǔn)類庫(kù)和開(kāi)發(fā)模式

4.5.8.1.?請(qǐng)使用慣用的代碼風(fēng)格和開(kāi)發(fā)模式

4.6.?封裝專業(yè)領(lǐng)域知識(shí)

4.6.1.?將軟件組件映射到業(yè)務(wù)領(lǐng)域，將使代碼的變化保持專注和干凈

4.6.1.1.?會(huì)計(jì)、計(jì)費(fèi)、運(yùn)輸?shù)?/h4>

4.6.2.?封裝的領(lǐng)域自然會(huì)傾向于高內(nèi)聚和低耦合

4.6.2.1.?理想的特征

4.6.2.2.?高內(nèi)聚和低耦合的軟件更容易演進(jìn)，因?yàn)樽兏摹氨ò霃健蓖?/h4>

4.6.2.3.?解耦的代碼是自成一體的，對(duì)其邏輯的改變不需要對(duì)其他軟件組件也進(jìn)行改變

4.6.3.?開(kāi)發(fā)人員經(jīng)常以“層”為單位來(lái)思考軟件：前端、中間層和后端

4.6.3.1.?每一層都有獨(dú)立的團(tuán)隊(duì)，會(huì)增加協(xié)調(diào)成本，因?yàn)槊恳豁?xiàng)業(yè)務(wù)邏輯的變化都會(huì)影響到所有的軟件分層

4.6.4.?識(shí)別領(lǐng)域邊界和封裝領(lǐng)域知識(shí)既是一門(mén)科學(xué)又是一門(mén)藝術(shù)

4.6.4.1.?領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(domain-driven design，DDD)，它定義了一套廣泛的概念和實(shí)踐，將商業(yè)概念映射到軟件上

4.6.4.2.?只有在最復(fù)雜的情況下才需要全覆蓋的DDD

4.6.4.3.?熟悉DDD將有助于你做出更好的設(shè)計(jì)決策

到了這里，關(guān)于讀程序員的README筆記16_構(gòu)建可演進(jìn)的架構(gòu)（上）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！