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

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

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

一個(gè)

問題討論和計(jì)劃

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

文件是初步的研究報(bào)告和項(xiàng)目開發(fā)計(jì)劃。

2

需求分析

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

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

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

三

軟件設(shè)計(jì)

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

總體設(shè)計(jì)

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

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

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

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

四

程序編碼

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

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

五

軟件測試

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

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

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

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

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

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

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

代碼都在一個(gè)代碼包里，哪怕修改一個(gè)小功能，整個(gè)項(xiàng)目都要打包上線；

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

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

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

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

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

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

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

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

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

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

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

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

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