586      阿裏雲  技術社區[雲棲]

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的項目的構建流程。

迭代

　　在互聯網行業裏，能越快速地對市場需求做出反應，就越能有更好的發展。隻要你細心觀察就可以發現，大部分互聯網公司都在以一定的規律更新產品，或者一周，或者兩周，又或者一個月等，這種不斷根據反饋來改進產品的過程稱為迭代。如圖0-4所示是一個簡化的迭代模型。
　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　圖0-4 簡化的迭代模型

　　　當一個迭代開始時，我們需要收集上一個迭代的反饋或者新的需求，然後開始開發代碼，最後再發布產品。開發的產品在這個過程中不斷地增強功能。為此，還需要選擇一個好的迭代周期。一個好的迭代周期既應該有充足的時間修複上一個迭代的Bug，又能在下一個迭代開始之前交付重要的功能。當然，如果交付的軟件包裏出現了重要的Bug，那麼我們也能在第一時間使用舊版本的包，並在下一個迭代交付。在這樣的開發節奏裏，一周顯得太短，一個月又顯得太長，兩周會是一個很不錯的時間。
　　當一個團隊在這方麵做得不好時，那麼他們可能在一次上線後，發現重要的Bug，不得不在當晚或者第二天更新他們的產品。即使是有經驗的團隊，在開發初期也會經常遇到這些問題，而這些問題可以依賴於在迭代中改進。好的迭代實踐都是依據團隊自身的需求而發展的，這意味著有時候適合團隊A的實踐並不一定適合團隊B。
　　隨後，我們會在這個“hello, world”的基礎上不斷添加各種功能。

Web應用開發步驟

　　令人難以置信的是，我們做了這麼多事情以後還沒有開始寫代碼。事實上，在這一步裏，我們已經搭建好了一個最小可運行的Web應用。在這之後，我們所要做的事情就是提交代碼即可。將代碼從本地提交到服務器後，持續集成服務器將幫我們運行測試，在測試通過後，打包、發布現有的代碼，最後部署到測試環境裏。

1 . 編碼

　　如果不考慮技術難度的因素，寫代碼看上去就是一件很簡單的事。我們隻需要按照需求，將功能一點點往上疊加即可。如果不考慮這個過程中添加的代碼質量，將會得到一個難以維護的係統，並且在拿到需求後的第一反應也並非直接開始實現功能，而是首先應該考慮可以將這個需求拆分為幾步，我們將這個過程稱為Tasking。
　　假如，我們正在實現某個詳情頁的顯示功能，它依賴於前端和後台。那麼可以直接先做後台API，再實現前台API，最後依據需要微微調整API。我們也可以先用Mock的數據實現前端頁麵，再依據定義出來的數據格式實現後台API。在這兩種不同的實現中，我們都有一個明確的先後步驟。同樣，對於一個更加複雜的功能來說，需要切分得更加仔細，每一次隻挑選其中一個任務，實現後，再一步步往下執行，最後實現這個功能。
　　有意思的是，當我們已經決定切分為多步來實現功能的時候，就可以在每一步裏進行幾次不同的代碼提交，以便以後知道每一步中做了什麼內容。如果隻是在最後一步直接提交代碼，那麼在未來修改代碼時，便難以理清當時的思路。
　　一個合理的編碼過程不僅包括功能的實現，還應該有測試。盡管出於項目進度的原因，多數項目都不存在測試，而正是因為沒有測試，使得整個項目更加混亂。新的功能容易影響舊有的代碼，除非有足夠多的測試人員，否則我們無法保證所有的功能都是正常的。在有限的條件下，我們應該編寫重要的測試，以保證核心功能不被破壞。在條件允許的情況下，我們應該盡可能地保證測試對重要功能的覆蓋。由於代碼庫不隻有一個人在提交，如果在某次提交中測試被破壞了，就可以知道誰破壞了測試，他/她應該有責任來修複這個測試。
　　在完成功能後，我們還可以對代碼進行重構，以此來保證代碼的質量。此外，在日常工作中，我們會用Code Diff（代碼檢視）來幫助大家提高代碼質量。因此，並不是實現了功能就完事了，我們應該盡量保證代碼的質量。

2 . 上線和數據分析

　　好了，現在是時候上線了。在以前，上線就是登錄到服務器做數據備份。隨後，在本地構建、上傳軟件包，安裝軟件的依賴。最後，重啟服務器、Done。
　　在今天看來，這是一件相當費力的事，我們可以使用自動部署工具來加快這個流程，甚至當我們有足夠的測試覆蓋率時，可以直接將測試通過的代碼直接部署到產品環境。不過，要這樣做應有相當的技術能力，並且要保證我們可以協調好開發人員、運維人員等。從技術上說，這可能是一件容易的事，但是從組織結構上說，這並不是一件輕鬆的事。
　　而故事並沒有因此而止步於上線，在產品上線時，我們可以通過數據分析工具來監測用戶的行為、網站的訪問量等信息。
　　對開發人員來說，這樣的分析平台可以幫助我們解決用戶在使用過程中遇到的Bug—他在哪一步出的問題？他在出問題前做了什麼操作？
　　對業務人員來說，他們可以借此來分析產品受歡迎的程度、用戶及流量來源、轉化率等信息，並依此來對著陸頁、轉化率等進行優化。幾種常見的流量來源包括搜索引擎、外部鏈接、付費搜索等，這些都可以依此來做出一些調整。從技術角度說，我們可以提高網站的SEO（搜索引擎優化）水平來添加流量，這將在《全棧應用開發》一書第7章中進行討論。

小結

　　本篇文章是對《全棧應用開發：精益實踐》這本書的一個簡單概述，點此鏈接可在博文視點官網查看此書。
　　　　　　　　　　　　　　　　　　　　　　
　　《全棧應用開發》這不是一本深入前端、後台、運維、設計、分析等各個領域的書籍，而是以實踐的方式，將這一係列的領域及理論知識結合到一起來幫助讀者構建全棧Web 開發的知識體係，並輔以精益及敏捷的思想，來一步步開發Web 應用。
　　　　想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼並關注。
　　　　　　　　　　　　　　　　　　　　　　　　　

最後更新：2017-06-06 10:01:34

  上一篇：  zabbix v3.2.3安裝部署

  下一篇：  五大機器學習微信公眾號推薦