Web應用開發週期

標籤：顯示   skin   net   yun   品質   休息   dem   資料   能力   

原文連結

摘要： 這部分內容最早出自筆者寫的文章《RePractise：Web開發的七天裡》，原文簡單描述了Web應用的生命週期。後來發現，這條路幾乎是所有Web應用的必經之路。一個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 應用程式。

原文連結

Web應用開發週期