“云、架構(gòu)即代碼、具有API和反脆弱系統(tǒng)的聯(lián)邦架構(gòu)，這些軟件系統(tǒng)開發(fā)技術(shù)正迅速成為關(guān)注焦點”。這是Mary Poppendieck在GOTO Berlin 2016大會上做“軟件工程技術(shù)的未來”演講時所提出的。

當數(shù)據(jù)量大到無法被單機所管理時，有兩個解決方案，即縱向擴展和橫向擴展。縱向擴展通過擴容單機的能力實現(xiàn)，Poppendieck指出通常這并非是解決問題的正確方向。很多情況下需要做橫向擴展，通過添加更多的計算機構(gòu)建集群系統(tǒng)。

Poppendieck在演講中給出了兩種不同的橫向擴展方法：

• 文件的橫向擴展。以Google的搜索技術(shù)為例，文件被分割為多個小塊并分別拷貝到多個服務(wù)器中。這樣搜索可并行地完成，并通過合并各個服務(wù)器所給出的結(jié)果得到最終的搜索結(jié)果。

• 架構(gòu)的橫向擴展。以Amazon的做法為例，事務(wù)會被切分為多個服務(wù)，每個服務(wù)使用特定服務(wù)器實現(xiàn)。當事務(wù)存在瓶頸時，可在多個服務(wù)器上復(fù)制服務(wù)，并且每個服務(wù)由一個半自治的“雙比薩”團隊（譯者注：“雙批薩”原則指團隊規(guī)模不應(yīng)超過兩個披薩餅還不夠吃的人數(shù)）負責。

Poppendieck提到，越來越多的系統(tǒng)正在向云上遷移，云就是未來。她指明：

相比于大多數(shù)預(yù)制的數(shù)據(jù)中心，云更便宜、更穩(wěn)定、更安全并且更具擴展性。

將已有的應(yīng)用轉(zhuǎn)化為基于云的應(yīng)用是十分具有挑戰(zhàn)性的。Poppendieck引用了IBM的Arthur Cole所說的話：

針對傳統(tǒng)數(shù)據(jù)架構(gòu)所設(shè)計的應(yīng)用如果不做大量的代碼重構(gòu)工作，就無法在云中很好地運行。

Poppendieckz在演講中給出了幾個已有的架構(gòu)即代碼解決方案：

• 使用容器，實現(xiàn)了過程的標準化和自動化。

• 無服務(wù)器架構(gòu)，以更低的價格提供了靈活的計算容量。

• 軟件定義網(wǎng)絡(luò)，使用軟件而非硬件實現(xiàn)了規(guī)模擴展。

單一的中央數(shù)據(jù)庫會產(chǎn)生依賴性問題，這是由于所有的應(yīng)用都依賴于數(shù)據(jù)，數(shù)據(jù)庫的改變將會影響到很多的應(yīng)用。Poppendieck指出：“企業(yè)數(shù)據(jù)庫是一個巨大的依賴性生成器”。由于每個獨立團隊的工作必須要和其它共享同一數(shù)據(jù)庫的團隊協(xié)作，這導(dǎo)致每個團隊都無法實現(xiàn)自治的部署。聯(lián)邦架構(gòu)是單一數(shù)據(jù)庫的替代技術(shù)，它將數(shù)據(jù)分割為適合各個獨立模塊或服務(wù)需求的本地數(shù)據(jù)存儲，數(shù)據(jù)的存取只能通過API方法。API正在替代中央共享數(shù)據(jù)庫，并使物聯(lián)網(wǎng)成為可能。Poppendieck指出，使用API是軟件工程的必備技術(shù)。API應(yīng)作為有具體團隊負責的產(chǎn)品看待，并通過聚焦于API用戶來推進和開發(fā)新的功能。

Poppendieck說，沒有必要盡力去實現(xiàn)系統(tǒng)零故障，我們可以換一種思維。當前很多的系統(tǒng)都是脆弱的，雖然它們在剛上線時都是魯棒的，但是隨著時間的進展，它們變得越發(fā)地難以維護。Poppendieck提出，當今系統(tǒng)需要的是反脆弱，并具有面對故障的能力。在發(fā)生故障時，系統(tǒng)應(yīng)能限定損害的程度，并從故障中恢復(fù)。

如何獲取反脆弱系統(tǒng)取決于系統(tǒng)測試的方法，即如何通過注入故障產(chǎn)生給定的運行錯誤。Poppendieck指出，為達到所期望的可用性和魯棒性等級，系統(tǒng)需要隔離故障并從故障自動恢復(fù)。

Poppendieck提到了當前開發(fā)軟件的關(guān)鍵事宜，她說，為具備持續(xù)集成的能力，需要一個部署流水線；為獲得持續(xù)集成所承諾的優(yōu)點，需要具有一個包括產(chǎn)品管理、測試和運營的跨功能團隊。部署流水線依賴于自動的測試、遷移和部署過程。持續(xù)集成需要所有團隊通過代碼庫做交流，實現(xiàn)針對主干分支的持續(xù)集成。團隊應(yīng)維持軟件時常處于發(fā)布就緒的狀態(tài)，如果事實并非如此，你必須停下來并做到上述要求。只要實現(xiàn)了持續(xù)的部署，一旦有用的軟件增量或功能就緒，就可通過切換或轉(zhuǎn)換實現(xiàn)軟件的增量發(fā)布。

Poppendieck提出，持續(xù)交付提供了必要的端到端反饋。研究顯示在半數(shù)情況下產(chǎn)品經(jīng)理是錯的，產(chǎn)品規(guī)格說明中會有三分之二的特性和功能是沒有必要的。導(dǎo)致這些問題產(chǎn)生的原因在于做實驗驗證某個特性是否可以真正地解決手頭問題之前，就試圖達成具體開發(fā)特性的細節(jié)。為確保開發(fā)的解決方案能很好地適用于所需解決問題，需要通過實際的使用產(chǎn)生快速的反饋，這也正是精益開發(fā)和敏捷開發(fā)實踐的真正價值所在。Poppendieck建議將發(fā)布團隊轉(zhuǎn)變?yōu)樵谝欢l件下可解決問題的團隊。

Poppendieck建議在系統(tǒng)開發(fā)的過程中采用基本的工程性過程實踐、在現(xiàn)實制約因素的范圍內(nèi)學習，并且建議從模式或者信號而非需求或是特性開始。然后聚焦于問題本身并使用假設(shè)去規(guī)劃工作。基于上述方法，開展多個實驗并使用實驗結(jié)果數(shù)據(jù)決定應(yīng)如何繼續(xù)工作。

原文地址：http://www.infoq.com/cn/news/2016/12/future-software-engineering

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關(guān)注

總結(jié)

以上是生活随笔為你收集整理的软件工程技术的未来的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。