爲何全部的 Web 應用都將被重寫？——Web 應用的生命週期

一個Web應用在其生命週期裏，都要經歷搭建開發環境、建立構建系統、編寫代碼、進行數據分析等等，直至最後使用新的系統來替換這個遺留系統。

Web應用的生命週期

在我所經歷的項目以及我所看到的Web應用裏，它們都有相同的頗有意思的生命週期。咱們常常在網上看到某個知名的網站使用某個新的技術、語言來替換舊的系統，某個APP使用開發新的框架來替換現有的APP。咱們所看到的都只是這些公司正在重構現有的系統，這其實是一個週期的結束，以及一個新的週期的開始。其過程以下圖所示：

仔細一想就會發現：咱們所經歷的項目，都在以不一樣的時間長度經歷相同的生命週期。

遺留系統與新架構

在我開始工做的時候，接觸的第一個項目就是一個遺留系統。在一次休息時，咱們在比賽找最古老的源碼文件，最後找到了一個10年前寫下的文件。儘管在咱們的代碼裏有單元測試、針對具體業務功能的測試，項目的代碼已經超過20萬行，項目中仍然有至關多的代碼超出了咱們所理解的業務範圍。畢竟在這些年頭裏，有至關多的功能已經不存在了。後來，咱們選用微服務重構了這個系統。對於中型的遺留系統來講，這算是一劑良藥。

讓咱們先從某某網站使用新架構從新設計提及。當咱們決定使用新架構從新設計系統，緣由多是多種多樣的，若是咱們排除一些沒法抗拒的因素，如政治，那麼剩下的緣由可能就只有兩個：

1. 系統已經變得難以維護。這裏的緣由仍然有不少：大量的代碼已經沒有人知道其業務邏輯，變得難以修改；代碼間耦合度太高，重構系統的難度過於複雜；項目所使用的技術棧已通過時，已經被市場所淘汰；團隊的技術棧在成員變更的過程當中，團隊中的大部分紅員的技術棧已經和當前的項目不匹配了。

2. 系統的技術棧已經難以符合業務的需求。絕大多數狀況下，咱們在最初的開始建立項目的時候，所選擇的技術棧都是符合當時業務需求的技術棧、能夠快速驗證其業務價值的技術棧。而隨着業務的擴張，現有的技術棧很快將難以知足當前業務的需求，或出現性能優化上的限制。

在多數狀況下，咱們都會將這種系統稱之爲遺留系統。在這時團隊裏的氣氛，即是「能不動這些代碼就儘可能不去動它」。咱們已經很難將項目的問題歸根到人的因素上，多數的時候都是受業務擴張的影響。

做爲一個專業的程序員，咱們的本能就是將程序寫好。而咱們每每沒有這樣的機會：

業務人員對項目經理說：「咱們的競爭對手已經在本週上線了這個功能」。

項目經理對開發人員說：「這個功能下星期就要上線！」

是的，咱們的功能不得不立刻上線。這時候，咱們每每要在代碼質量和交付速度上做出一些妥協。妥協多了，系統也就變爛了。

開發人員：「這個代碼我不太敢修改，要是出了什麼大bug怎麼辦？」。慢慢地人們就開始討論起重構系統的事宜，並開始着手設計新的架構—使之能夠知足當前的業務需求、可預測時間內的業務與技術需求。

技術選型與驗證

在咱們討論新的架構的過程當中，不一樣的人可能會有不一樣的技術偏好，也會因存在一些政治因素致使不一樣技術方案的產生。如團隊中的一些人可能出於穩定緣故而使用Java，而一些人可能出於對新技術的需求使用Scala，而團隊中大部分會可能由於都會使用JavaScript而選擇使用JavaScript。以下圖所示，咱們的考慮應該不只僅取決於這一系列的技術因素：

須要注意的是：在作技術選型的時候盡，要盡最大可能的以團隊爲核心。在咱們最後決定以前，咱們要提出不一樣語言、框架下的技術模型，而且進行驗證。隨後咱們就須要快速搭建出一個原型，並針對這個原型進行假想式開發，而後驗證原型自己是經得起考驗的。

在這一階段，我一般喜歡在GitHub上搜索一些名字中帶有boilerplate的項目，即模塊文件。而當一個框架很流行的時候，我就會去相應的awesome-xx尋找，如awesome-react就能夠尋找到react相關的項目集。而後，咱們Clone這樣的一個項目，開始依照現有的系統建立簡單的Demo。隨後，咱們就能夠依據咱們的業務試圖在這上面進行擴展。最後，再決定是否使用這門技術、是否使用這個框架。

一般來講，在選擇一門新技術來設計系統時，須要承擔的風險至關的大，而若是能成功的話，那麼它也極可能會帶來巨大的收益。從這裏看，使用最新的技術和賭博無益。在一些成熟的公司裏，會有專門的技術委員會負責對新技術進行審覈，來決定是否能夠在某個項目裏使用新的技術。除了，考慮其爲開發帶來的便利性，他們更多的會考慮其成熟度、安全以及技術風險等等。

搭建構建系統

決定好了架構、選擇完技術棧後，咱們就得着手於建立項目的構建系統，設計項目的部署流程。構建系統不只僅包含了項目相關的構建流程，還從某種意義上反應了這個項目的工做流程。

在咱們建立完hello, world程序後，咱們要着手作的事情就是建立一個持續集成環境。這樣的環境包含了一系列的工具、步驟及實踐，從工具上來講，咱們須要選擇版本管理工具、代碼託管環境、持續集成工具、打包工具、自動部署腳本等等一系列的流程，這些流程將會在「第四章 構建流及工做流」進行詳細的討論。

下圖即是筆者以前經歷過的一個項目的構建流程：

這是一個後臺語言用的是 Java，前臺語言用的是 JavaScript 的項目的構建流程。

迭代

在互聯網行業裏，能越快速地對市場需求作出反應，就越能有更好的發展。只要你細心觀察就能夠發現，大部分的互聯網公司都在以必定的規律更新產品，或者一週，或者兩週，又或者是一個月等等，這種不斷地根據反饋來改進產品的過程稱之爲迭代。以下圖是一個簡化的迭代模型：

當一個迭代開始時，咱們須要收集上一個迭代的反饋，又或者是新的需求，而後開始開發代碼，最後再發布咱們的產品。咱們開發的產品在這個過程當中，不斷地加強功能。爲此，咱們還須要選擇一個好的迭代週期。一個好的迭代週期，即應該有充足的時間，便可以修復上一個迭代的Bug，又能在下一個迭代開始以前交付重要的功能。固然，若是不幸交付的軟件包裏出現了重要的Bug，那麼咱們也能在第一時間使用舊版本的包，並在下個迭代交付。固然在這樣的開發節奏裏，一個星期顯得過短，一個月又顯得太長，兩星期會是一個很不錯的時間。

當一個團隊在這方面作得很差時，那麼他們可能在一次上線後，發現重要的bug，不得不在當晚又或者是次日更新他們的產品。即便是有經驗的團隊，在開發的初期也會常常遇到這些問題，而這些問題能夠依賴於在迭代中的回顧來改進這些流程問題。好的迭代實踐都是依據團隊自身的需求而發展而來的，這意味着有時候適合團隊 A 的實踐並不必定適合團隊B。

隨後，咱們就會在這個 hello, world 的基礎上不斷地添加各類功能。

節選自：《全棧應用開發：精益實踐》

亞馬遜：《全棧應用開發：精益實踐》 黃峯達【摘要 書評 試讀】圖書
京東：《全棧應用開發：精益實踐》(黃峯達)【摘要 書評 試讀】- 京東圖書
噹噹：《全棧應用開發：精益實踐》(黃峯達)【簡介_書評_在線閱讀】 - 噹噹圖書