業(yè)務(wù)迭代和技術(shù)優(yōu)化難以兼顧

重要的事：架構(gòu)設(shè)計優(yōu)化，讓系統(tǒng)具有足夠的“彈”性

緊急的事：業(yè)務(wù)迭代支持，讓系統(tǒng)支撐業(yè)務(wù)持續(xù)發(fā)展

我們將日常中的事情分為重要、緊急四個象限，然后對系統(tǒng)架構(gòu)優(yōu)化和業(yè)務(wù)迭代填空在四個象限內(nèi)。

1）重要且緊急

2）重要不緊急

3）不重要但緊急

4）不重要且不緊急

系統(tǒng)架構(gòu)設(shè)計優(yōu)化：重要（占據(jù)第 1、2 位）

業(yè)務(wù)迭代支持：緊急（占據(jù)第 1、3 位）

但是我們?nèi)粘９ぷ髦?，業(yè)務(wù)、產(chǎn)品與研發(fā)部門經(jīng)常犯的錯誤就是將第三優(yōu)先級的事情提到了第二優(yōu)先級去做。顯而易見重要的系統(tǒng)技術(shù)優(yōu)化事項被業(yè)務(wù)迭代所排擠。為此我們研發(fā)人員經(jīng)常會抱怨，沒有時間來做技術(shù)優(yōu)化，自我調(diào)侃為：“又在搬磚...”、“又在加班寫 BUG ...”

似乎我們忘記了：業(yè)務(wù)部門就是只盯著業(yè)務(wù)的，對于系統(tǒng)架構(gòu)的評估和優(yōu)化，本來就是研發(fā)人員的工作職責(zé)！如何平衡好這兩者的工作，是研發(fā)人員的晉級修養(yǎng)之路。

不要忽略系統(tǒng)架構(gòu)的價值，假如有一天系統(tǒng)難以維護到只能推翻重來的地步，可以說是系統(tǒng)技術(shù)優(yōu)化跟不上業(yè)務(wù)的快速迭代，同時側(cè)面說明了研發(fā)同學(xué)的本職工作做得不夠格！

缺少“上帝”視角思維

我們在以往的需求迭代中更多的是掉入到“需求陷阱”里，只關(guān)注自己負責(zé)的業(yè)務(wù)部分，而忽視“全局”。緊密的需求迭代節(jié)奏也是我們忙于堆砌代碼，從而忘記停下腳步來回頭看看是否走在了岔路上。我們都知道最終都會達到羅馬，但是有的人走的是“直道”，有的人走得是“彎道”。我們要時不時跳脫出來，回過頭來重新審視一下全局的業(yè)務(wù)、產(chǎn)品、系統(tǒng)設(shè)計是否合理。

系統(tǒng)架構(gòu)腐化

多人協(xié)作問題：如果系統(tǒng)的開發(fā)人員沒有嚴(yán)格遵循一致的開發(fā)規(guī)范，或者沒有建立好有效的代碼管理機制，可能會導(dǎo)致代碼結(jié)構(gòu)上的混亂，從而增加系統(tǒng)的開發(fā)復(fù)雜度和維護成本。

無規(guī)劃性的技術(shù)棧升級：開發(fā)人員過于頻繁地嘗試新技術(shù)，不僅會使技術(shù)棧變得復(fù)雜，也可能會影響系統(tǒng)的穩(wěn)定性和安全性。

缺乏良好的測試機制：系統(tǒng)的測試機制如果缺乏，可能會嚴(yán)重影響代碼質(zhì)量，就像沒有人為項目提供反饋似的，從而使代碼中的錯誤不被及時發(fā)現(xiàn)，令錯誤在系統(tǒng)中逐漸積累。

研發(fā)人員變動：如果組織的團隊成員經(jīng)常性更換，新舊人員之間沒能形成有效的銜接和匹配，可能會導(dǎo)致系統(tǒng)的連續(xù)性和穩(wěn)定性受到影響，乃至出現(xiàn)系統(tǒng)架構(gòu)腐化的問題。

系統(tǒng)逐漸復(fù)雜化：在系統(tǒng)的長周期的演化過程中，難免會增加新需求、新功能模塊和服務(wù)組合, 由此引進新框架、新模型。然而在此過程中，如果沒有及時做好架構(gòu)積累和提前預(yù)估架構(gòu)變動的影響，可能會導(dǎo)致系統(tǒng)逐漸變得復(fù)雜，就像人體長期積累毒素一樣，最終帶來嚴(yán)重的后果。

總之，系統(tǒng)的架構(gòu)腐化可能源自于開發(fā)人員、組織和系統(tǒng)本身等多方面原因，需要我們在系統(tǒng)的開發(fā)、測試、運維和補救中，有針對性地逐一落實。「預(yù)防勝于治療」，預(yù)防性戰(zhàn)略是減少系統(tǒng)架構(gòu)腐化的關(guān)鍵環(huán)節(jié)。

缺少架構(gòu)師視角

產(chǎn)品需求把控：我們平時的研發(fā)工作中缺少架構(gòu)師思維，缺少結(jié)合產(chǎn)品、技術(shù)層面的全局把控，沒有在產(chǎn)品需求階段指出合理的需求方案，導(dǎo)致在開發(fā)階段出現(xiàn)需求不通臨時需求變更。

缺少系統(tǒng)分解思維：系統(tǒng)分解一般分為縱向分解和橫向分解，縱向分解是將整個系統(tǒng)拆分，從而將整體系統(tǒng)分解成下一級的子系統(tǒng)與組件。橫向分解是在系統(tǒng)分解成不同的邏輯層或服務(wù)后，對邏輯層進行分塊，確定層與層之間的關(guān)系。由于在系統(tǒng)設(shè)計的時候缺少分解思維，導(dǎo)致實現(xiàn)的系統(tǒng)“大而邊界不清晰”。

通常架構(gòu)師也不太會跟每一個需求，這就需要我們團隊中的高階同學(xué)，負起必要的責(zé)任，尤其要基于技術(shù)細節(jié)盡量站在全局視角最好技術(shù)把關(guān)。

系統(tǒng)迭代機制

做項目而非做產(chǎn)品：軟件系統(tǒng)的開發(fā)和演進有很多驅(qū)動因素，導(dǎo)致系統(tǒng)更加復(fù)雜的是按照特定需求開發(fā)特定功能，也就是做項目的方式。每次都有明確的目標(biāo)，而且這個目標(biāo)的方案多數(shù)也是設(shè)計好的。

做項目的方式對系統(tǒng)最直接的影響就是需求的一致性或幾次迭代，多個不同的項目作用在同一個系統(tǒng)上，為了解決不同的問題，單純的疊加功能，缺少對這個軟件系統(tǒng)的整體認知和規(guī)劃。而不像做產(chǎn)品，每一款產(chǎn)品都有一個愿景和核心要解決的問題，任何不符合愿景或者無法幫助解決核心問題的需求都是偽需求，不應(yīng)該被添加到這個系統(tǒng)中。

因此，以做項目的方式推進的軟件系統(tǒng)，隨著項目不斷的推進，多個不相關(guān)或沒有經(jīng)過深思熟慮的需求疊加到系統(tǒng)中，也會不斷加劇軟件系統(tǒng)的復(fù)雜度。而事實就是我們的現(xiàn)狀就是按照項目制去進行軟件開發(fā)，這種問題在所難免但是我們可以在同一個系統(tǒng)中做好業(yè)務(wù)分層，不同的業(yè)務(wù)盡量隔離。

設(shè)計規(guī)范把控

TechnicalDebtQuadrant上圖來自大名鼎鼎的“MartinFowler”，MartinFowler將技術(shù)債按照 魯莽的（Reckless）/謹慎的（Prudent） 以及 故意的（Deliberate）/無心的（Inadvertent） 劃分到4個不同的象限中。

謹慎的 且 故意的：這種場景很常見，是已知技術(shù)債的一種主要來源。為了讓產(chǎn)品快速投入市場，獲得更大的收益，通常團隊會選擇更快速的方案，開發(fā)成本低，時長短，但解決方案并不是最優(yōu)，且可能只是臨時方案。然而，團隊對技術(shù)選擇做了詳盡的評估，了解技術(shù)債產(chǎn)生后給產(chǎn)品和架構(gòu)會帶來什么影響，后果是可估量的，甚至已經(jīng)安排好了未來的改進計劃。

魯莽的 且 故意的：相比上一個分類而言，團隊知道當(dāng)前的方案不是最優(yōu)選擇，但通常由于時間緊迫，實現(xiàn)當(dāng)前的業(yè)務(wù)需求是第一優(yōu)先級的，未對當(dāng)前的方案做細致的分析，因此對遺留技術(shù)債可能產(chǎn)生的影響是未知的，甚至具體產(chǎn)生了哪些問題也可能是未知的。

魯莽的 且 無心的：不計后果而又是無心之舉，這往往是因為團隊成員的認知還不足以判斷當(dāng)前的選擇是不是會帶來不良影響。這種技術(shù)債在技術(shù)債總體的占比很高，甚至可能比上面提到的第一種技術(shù)債更多。因為不管怎樣的團隊，人員的更替都是避免不了的，個人的經(jīng)驗不同，認知不同，在實現(xiàn)相同的功能時選擇的方案也是不同的，雖然可以通過一些社交活動來減少不同團隊成員的認知差異，如代碼評審，但想通過這種方式來避免技術(shù)債的產(chǎn)生，效果往往并不是很好。

謹慎的 且 無心的：這種技術(shù)債看上去讓人難以理解，既然每次都是深思熟慮，為什么還會有無心之失。然而，這種技術(shù)債確實也是無法避免的，甚至?xí)?jīng)常遇到，最簡單的莫過于當(dāng)下基于當(dāng)下的經(jīng)驗甚至業(yè)界最優(yōu)的一些實踐選擇的技術(shù)方案或者技術(shù)框架，而隨著技術(shù)的進步和發(fā)展，它們的弊端和問題也會逐漸顯現(xiàn)出來，這些過時的技術(shù)方案設(shè)計和框架也就成了技術(shù)債。

解決

技術(shù)債解決日?；?/span>研發(fā)團隊要有守護架構(gòu)的意識，在項目日常開發(fā)中，除了產(chǎn)品的業(yè)務(wù)需求外，應(yīng)該規(guī)劃一部分工作用于架構(gòu)的優(yōu)化，修復(fù)那些已知且有解決方案的技術(shù)債，這樣才能持續(xù)保證軟件系統(tǒng)的響應(yīng)能力和產(chǎn)品質(zhì)量。

明確研發(fā)規(guī)范，加強管理：對于已知且無解決方案的問題，只是沒有深入思考對系統(tǒng)的影響，對于這部分技術(shù)債，為了讓這些技術(shù)債在產(chǎn)生前就避免，或者引導(dǎo)到可以快速解決的方向，首先，需要建立團隊的技術(shù)規(guī)范和標(biāo)準(zhǔn)，讓每個決策都有依據(jù)。其次，加強流程上的管理，建立架構(gòu)評審委員會，對架構(gòu)的修改進行評審，一方面規(guī)避問題，另一方面根據(jù)問題完善規(guī)范和標(biāo)準(zhǔn)。

持續(xù)關(guān)注技術(shù)發(fā)展趨勢，提前規(guī)劃：隨著技術(shù)的不斷發(fā)展，很多幾年前被認為非常先進的技術(shù)表現(xiàn)出了一些弊端，也逐漸在被新的技術(shù)替代。研發(fā)團隊需要持續(xù)保持對技術(shù)發(fā)展趨勢的關(guān)注，探索是否有更優(yōu)的解決方案文章來源地址http://www.zghlxwxcb.cn/news/detail-516876.html