code小生，一個(gè)專(zhuān)注大前端領(lǐng)域的技術(shù)平臺
每天 8.40 推送技術(shù)文章
軟件架構設計是個(gè)不老的話(huà)題，隨著(zhù)業(yè)務(wù)驅動(dòng)，技術(shù)展現形式隨之變化，從當初的“堆”模式開(kāi)發(fā)到后來(lái)有點(diǎn)模型的形式（功能分包但無(wú)模式），再到后來(lái) MVC 的出現，結束了“堆”模式，再到后來(lái) MVP 模式出現，一部分開(kāi)發(fā)者積極嘗試，或重構，或運用，得到了很多的認可，后面又出現了雙向綁定架構— MVVM，算是繼 MVP 之后的又一經(jīng)典架構；當然 Android 官方也推薦了架構：AAC（Android Architecture Components），后面，還會(huì )繼續出其他的架構...
之所以需要架構，是為了項目業(yè)務(wù)可以更好地可持續發(fā)展；沒(méi)有哪個(gè)架構是最好的，所有的架構都是建立在業(yè)務(wù)基礎之上，撇開(kāi)業(yè)務(wù)講架構都是空談。
那么如何選擇架構又成了一個(gè)問(wèn)題，這就需要必須熟悉每個(gè)架構的優(yōu)點(diǎn)和靈活性。
從實(shí)際角度看，優(yōu)秀的軟件架構不應該進(jìn)行過(guò)度設計，否則可能帶來(lái)維護者成本。
軟件架構設計亦應堅固可靠，以應對內外界多種不同類(lèi)型的攻擊，提供可靠、精準的輸出。面對外界的變化，響應要迅速及時(shí)。同時(shí)還要做到靈活可擴展。
同樣，軟件架構也應具備美觀(guān)性，代碼要簡(jiǎn)潔，易于閱讀、維護、能使維護者從直觀(guān)上對功能產(chǎn)生更清晰的認識，從而能夠快速地處理變化。優(yōu)秀的軟件架構亦是組件抽象，沒(méi)有復雜依賴(lài)關(guān)系，易于擴展分離的。
出自《移動(dòng)開(kāi)發(fā)架構設計實(shí)戰》
架構的演變很快，我們其實(shí)完全不必糾結于自己實(shí)用的架構是否過(guò)時(shí)，而更應該關(guān)注架構是否適合業(yè)務(wù)，剩下的我們關(guān)注演變過(guò)程即可，就像下圖羅列的，如果我們一個(gè)勁地去使用，恐怕每天都是在重構...
出自《移動(dòng)開(kāi)發(fā)架構設計實(shí)戰》一書(shū)
我們所接觸到的技術(shù)，90%都是前人研究過(guò)的，有很多樂(lè )于分享的開(kāi)發(fā)者，他們傾情于博客，所以要學(xué)習某個(gè)架構并不難，只要你會(huì )搜索，我相信都可以學(xué)會(huì )，這是一種途徑。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
