about 5 years ago

第 2 件事:application deployable from day 1

在進入開發階段後,我會做的第一件事: ** make application deployable**

也就是:專案開始第一天,就必須要有個 production 直接可運行(可以鎖密碼,當作測試 server)才行。(我在 Rails 101 這本書最後一章,加入 capistano 與裝機為必練技能,就是這個緣故。)

為什麼專案需要 deployable?

提前控制風險:開發環境與線上環境的不同

在一般的經驗中,往往在在專案進行到尾聲快上線之時,才會注意到一個可能使專案時程大爆炸的事情:** 開發端與線上端的環境通通不一樣 **。

在開發過程中,所有人只專注在自己的機器上能不能動,這是常態。專注在實現功能,東西有缺就先在 local 上塞假資料。在最短時間內將 feature 盡可能寫完絕對是第一要務。

但很可惜的,寫完並 不等於 放到正式環境上可以動。

網站上其實非常多功能需要實際被「真人」測試,才會知道到底有沒有問題。有一些設定,甚至開發環境與上線完完全全不一樣。(以 Rails 來說,其實就差很多。比如說程式 class 會不會被 cache,asset 有沒有 optimize,上傳路徑以及與第三方接軌的設定等等...)

如果拖到最後一個月才作 deploy 的這件事,因為「到底有多少東西不一樣」,變成了一個完全的未知數。原本夠用的一個月測試期,被這樣一壓縮可能完完全全就不夠用了。而且因為專案截止日已進,隨之而來的壓力更加大了犯錯的可能性。

一個透明的已知進度

Day1 就有一個可以直接實際測試的站台,還有一個很大的好處,能夠確保專案中所有人都知道現在進度,與規格書上的東西到底差多少。如果有重大瑕疵,或者是絕對不可行的功能,就可以早早會提出修改,下架等等。節省大家寶貴的開發精力。

如果專案截止日最後十五天,大家才知道很多東西原來根本是作不出來的,或者是跟原本想像差太多的,這時候鐵定陷入交相指責,一遍慌亂的狀況。

絕對注意:捍衛進度

不過這一招的使用,專案經理或者是 RD 主管要特別注意。因為 Day 1 就有一個直接可以看的站台,不少完全不懂「技術」的專案參與者(通常是企劃或老闆),會對網站的「裸站」狀態感到極度的恐慌,他們會挑剔 UI,會不滿 implement 細節,進而想要實際插手進度修改內容。請務必堅持住,堅持到進入最後一個階段:測試修飾期才可以讓他們修改(通常進入準完工階段,裸站狀態其實也消失了,當初挑剔的東西幾乎在這個階段不復存在,故也沒有修改的必要。)

P.S. 可以架設一個 issue tracking system,把他們提出的修改事項先通通記起來,但通通不實作。等到接近測試期,再來看看這些當初的「建議」到底還有哪些實際需要被執行。

只有「完全不合實際應用」的東西,或者是「變更會讓實作方式更合理」的東西可以在整個開發期,被丟入排程中。

否則,他們的驚慌,會害這個專案完全結不了案。

====

系列文章:

← 網站程式上線前需要準備的事 (一) 網站程式上線前需要準備的事 (三) →
 
comments powered by Disqus