如何開發(fā)組件化、模塊化的web應(yīng)用？我是一名java軟件工程師，有10年的項目架構(gòu)經(jīng)驗。歡迎關(guān)注我，了解更多java前沿技術(shù)！目前，微服務(wù)用于實現(xiàn)模塊化的W開發(fā)一個小程序，都需要什么流程？一個問題討論

如何開發(fā)組件化、模塊化的web應(yīng)用？

我是一名java軟件工程師，有10年的項目架構(gòu)經(jīng)驗。歡迎關(guān)注我，了解更多java前沿技術(shù)！目前，微服務(wù)用于實現(xiàn)模塊化的W

開發(fā)一個小程序，都需要什么流程？

一個

問題討論和計劃

這個階段是軟件開發(fā)和需求的共同討論，尋找軟件漏洞及其可行性，給出建議，主要確定軟件開發(fā)目標(biāo)及其可行性。

文件是初步的研究報告和項目開發(fā)計劃。

2

需求分析

在確定軟件開發(fā)可行性的情況下，對軟件需要實現(xiàn)的各個功能進行詳細(xì)的需求分析。需求分析階段的目的是在系統(tǒng)工作中與用戶達(dá)成一致。

首先，收集和整理需求，編寫需求規(guī)格說明書，主要描述軟件開發(fā)的意圖、應(yīng)用目標(biāo)、作用范圍等方向。詳細(xì)說明系統(tǒng)將實現(xiàn)的所有功能。然后，制作需求設(shè)計文檔，其主要內(nèi)容與用戶需求說明書相似。用戶需求說明書是由用戶編寫的。;軟件需求規(guī)格說明書是由開發(fā)人員用通俗的語言編寫的。;的觀點和在開發(fā)商 的語言。

文檔是軟件需求說明書和數(shù)據(jù)需求說明書。

三

軟件設(shè)計

在這個階段，要根據(jù)需求分析的結(jié)果對整個軟件系統(tǒng)進行設(shè)計，如系統(tǒng)框架設(shè)計、數(shù)據(jù)庫設(shè)計等。軟件設(shè)計一般分為總體設(shè)計和詳細(xì)設(shè)計。

總體設(shè)計

①系統(tǒng)結(jié)構(gòu)設(shè)計:定義和設(shè)計軟件的模塊化以及軟件系統(tǒng)模塊之間的關(guān)系。

②數(shù)據(jù)設(shè)計:定義數(shù)據(jù)庫功能模塊的表結(jié)構(gòu)。數(shù)據(jù)庫設(shè)計應(yīng)該考慮未來的可伸縮性。

詳細(xì)設(shè)計:逐一給出每個關(guān)卡中每個程序的設(shè)計考慮。

文檔是總體設(shè)計規(guī)范、詳細(xì)設(shè)計規(guī)范和數(shù)據(jù)庫設(shè)計規(guī)范。

四

程序編碼

這個階段是將軟件設(shè)計的結(jié)果轉(zhuǎn)化為計算機可執(zhí)行的程序代碼(代碼規(guī)范)。

文檔是用戶手冊、操作手冊和模塊開發(fā)文件。

五

軟件測試

軟件設(shè)計完成后，要進行嚴(yán)格的測試，一旦發(fā)現(xiàn)整個軟件設(shè)計過程中存在的問題，就要進行修正。它可以是開發(fā)商 s內(nèi)部測試(internal test)或公共測試(public t

在軟件項目開發(fā)過程中，都有哪些常見的軟件架構(gòu)？

軟件產(chǎn)品的架構(gòu)通常隨著業(yè)務(wù)的發(fā)展而演進；本人從事軟件開發(fā)行業(yè)十幾年，遇到的軟件(企業(yè)應(yīng)用，本人從事Java開發(fā))架構(gòu)主要有以下幾種:

單體架構(gòu)一般來說，單體架構(gòu)是應(yīng)用所有的功能，只有一個代碼包，開發(fā)和部署都在一起，是比較傳統(tǒng)的架構(gòu)風(fēng)格；當(dāng)然，單一架構(gòu)也有很多缺點:

代碼越來越多，增加了代碼的復(fù)雜度；作為一名開發(fā)者我一定深受感動。每當(dāng)我修改一個老方法的時候，我都會格外小心，生怕影響到其他功能。

單一應(yīng)用需要統(tǒng)一技術(shù)棧，團隊中的開發(fā)者需要掌握相同的開發(fā)語言和框架；

隨著開發(fā)人員的流動，老員工離開項目團隊，復(fù)雜龐大的項目代碼讓新成員難以閱讀和理解，技術(shù)欠賬不斷積累；

代碼都在一個代碼包里，哪怕修改一個小功能，整個項目都要打包上線；

所有模塊運行在同一個JVM中，非關(guān)鍵業(yè)務(wù)可能會占用大量資源，導(dǎo)致關(guān)鍵業(yè)務(wù)出現(xiàn)問題；不能單獨擴展一個模塊。

單一應(yīng)用架構(gòu)的缺點使得SOA架構(gòu)已經(jīng)不能滿足業(yè)務(wù)需求，于是SOA架構(gòu)出現(xiàn)了。

SOA架構(gòu)的主要思想是通過接口連接應(yīng)用程序的模塊化組件(接口可以獨立于語言、框架、硬件和操作系統(tǒng))；在SOA架構(gòu)中，有兩種主流實現(xiàn):

Web服務(wù):使用WSDL定義接口，用SOAP協(xié)議通信，傳輸XML數(shù)據(jù)；缺點是SOAP和XML比較笨重；服務(wù)管理不完善；

ESB:企業(yè)服務(wù)總線，各服務(wù)提供者通過總線插入系統(tǒng)，總線完成服務(wù)的排列和轉(zhuǎn)發(fā)；但是ESB本身就比較中等，本身就是單點。在軟件架構(gòu)中，單點意味著風(fēng)險。

微服務(wù)架構(gòu)微服務(wù)的出現(xiàn)也是因為SOA架構(gòu)的一些缺點。在這里，這句話再次得到印證，【應(yīng)用架構(gòu)的演進過程通常是業(yè)務(wù)所逼】。

在微服務(wù)架構(gòu)中，服務(wù)拆分的粒度更細(xì)，提高了可重用性；每個微服務(wù)都可以獨立開發(fā)部署；

Restful API通信通常用于微服務(wù)之間，和JSON通常被選作傳輸格式。

微服務(wù)是SOA架構(gòu)的延續(xù)。與單一應(yīng)用相比，它們大大提高了系統(tǒng)的負(fù)載能力，解決了應(yīng)用的高并發(fā)需求。

服務(wù)之間的耦合度也降低了，項目團隊可以分成幾個小團隊，每個微服務(wù)都可以部署在敏捷開發(fā)中。

只要遵守接口協(xié)議，每個團隊的技術(shù)堆棧也可以不同。

當(dāng)然，SOA和微服務(wù)的出現(xiàn)，在解決一些問題的同時，也帶來了其他問題，比如增加網(wǎng)絡(luò)開銷、服務(wù)依賴、增加測試運維難度、數(shù)據(jù)一致性等等。

我會繼續(xù)分享我對Java開發(fā)、架構(gòu)設(shè)計、程序員職業(yè)發(fā)展等方面的看法，希望得到大家的關(guān)注。