Web應用開發週期

全文連接

引言：這部份內容最先出自筆者寫的文章《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的項目的構建流程。