全文連結
引言：這部分内容最早出自筆者寫的文章《RePractise：Web開發的七天裡》，原文簡單描述了Web應用的生命周期。後來發現，這條路幾乎是所有Web應用的必經之路。一個Web應用在其生命周期裡，都要經曆搭建開發環境、建立建構系統、編寫代碼、進行資料分析等，直至最後使用新的系統來替換這個遺留系統。如果你是一個有經驗的開發者，相信你對這個生命周期一定也深有體會。 本篇文章是對《全棧應用開發：精益實踐》這本書的一個簡單概述。
Web應用的生命周期
在我所經曆的項目以及我所看到的Web應用裡，它們都有相同的很有意思的生命周期。我們經常在網上看到某個知名的網站使用某個新的技術、語言來替換舊的系統，某個App使用新的架構來替換現有的App。我們所看到的都隻是這些公司正在重構現有的系統，這實際上是一個周期的結束，以及一個新周期開始。其過程如圖0-1所示。
圖0-1 Web應用的生命周期
仔細一想就會發現：我們所經曆的項目都在以不同的時間長度經曆相同的生命周期。
遺留系統與新架構
在我開始工作的時候，接觸的第一個項目就是一個遺留系統。在一次休息時，我們在比賽找最古老的源碼檔案，最後找到了10年前寫下的一個檔案。盡管在我們的代碼裡有單元測試、針對具體業務功能的測試，項目的代碼已經超過20萬行，項目中仍然有相當多的代碼超出了我們所了解的業務範圍。畢竟在這些年頭裡，有相當多的功能已經不存在了。後來，我們選用微服務重構了這個系統。對于中型的遺留系統來說，這算是一劑良藥。
讓我們先從某某網站使用新架構重新設計說起。當我們決定使用新架構重新設計系統時，原因可能是多種多樣的，如果我們排除一些無法抗拒的因素（如政治），那麼剩下的原因可能就隻有兩個。
系統已經變得難以維護。這裡的原因仍然有很多：大量的代碼已經沒有人知道其業務邏輯，變得難以修改；代碼間耦合度過高，重構系統的難度過于複雜；項目所使用的技術棧已經過時，已經被市場所淘汰；團隊的技術棧在成員變動的過程中，團隊中大部分成員的技術棧已經和目前的項目不比對了。
系統的技術棧已經難以符合業務的需求。絕大多數情況下，我們在最初開始建立項目的時候，所選擇的技術棧都是符合當時業務需求的技術棧、可以快速驗證其業務價值的技術棧。而随着業務的擴張，現有的技術棧很快将難以滿足目前業務的需求，或出現性能優化上的限制。
在多數情況下，我們都會将這種系統稱為遺留系統。在這時團隊裡的氣氛便是“能不動這些代碼就盡量不去動它”。我們已經很難将項目的問題歸為人的因素，多數時候都是受業務擴張的影響。作為一個專業的程式員，我們的本能就是将程式寫好，而我們往往沒有這樣的機會。
業務人員對項目經理說：“我們的競争對手已經在本周上線了這個功能。”
項目經理對開發人員說：“這個功能下星期就要上線！”
是的，我們的功能不得不馬上上線。這時候，我們往往要在代碼品質和傳遞速度上做出一些妥協。妥協多了，系統也就變爛了。
開發人員說：“這個代碼我不太敢修改，要是出了什麼大Bug怎麼辦？”慢慢地人們就開始讨論起重構系統的事宜，并開始着手設計新的架構—使之可以滿足目前的業務需求、可預測時間内的業務與技術需求。
技術選型與驗證
在讨論新架構的過程中，不同的人可能會有不同的技術偏好，也會因存在一些政治因素導緻不同技術方案的産生。如團隊中的一些人可能出于穩定緣故而選擇Java，一些人可能出于對新技術的需求選擇Scala，而另外一些人可能考慮到團隊中大部分人可能因為都會使用JavaScript而選擇使用JavaScript。如圖0-2所示，我們的考慮應該不僅僅取決于這一系列的技術因素。
圖0-2 技術選型考慮因素
需要注意的是：在做技術選型的時候，要盡最大可能以團隊為核心。在做決定之前，我們要提出不同語言、架構下的技術模型，并且進行驗證。随後就需要快速搭建出一個原型，并針對這個原型進行假想式開發，然後驗證原型本身是經得起考驗的。
在這一階段，我通常喜歡在GitHub上搜尋一些名字中帶有boilerplate的項目，即子產品檔案。而當一個架構很流行的時候，我就會去相應的awesome-xx尋找，如awesome-react就可以尋找到react相關的項目集。然後，克隆這樣一個項目，開始依照現有的系統建立簡單的Demo。随後，就可以依據我們的業務試着在這上面進行擴充。最後，再決定是否使用這門技術和這個架構。
通常來說，在選擇一門新技術設計系統時，需要承擔的風險相當大，而如果能成功，那麼它可能會帶來巨大的收益。從這點看，使用最新的技術與×××無異。在一些成熟的公司裡，會有專門的技術委員會負責對新技術進行稽核，來決定是否可以在某個項目裡使用新技術。除了考慮其為開發帶來的便利性，他們更多地還會考慮其成熟度、安全和技術風險等。
搭建建構系統
決定好架構并選擇完技術棧後，我們就開始着手建立項目的建構系統，設計項目的部署流程。建構系統不僅包含項目相關的建構流程，還從某種意義上反映了這個項目的工作流程。
建立完“hello, world”程式後，我們要着手做的事情就是建立一個持續內建環境。這樣的環境包含一系列的工具、步驟及實踐，從工具上說，我們需要選擇版本管理工具、代碼托管環境、持續內建工具、打包工具、自動部署腳本等一系列流程，這些流程将會在《全棧應用開發》一書第4章詳細讨論。
圖0-3便是筆者之前經曆過的一個項目的建構流程。
圖0-3 建構過程
這是一個背景語言用Java、前台語言用JavaScript的項目的建構流程。