生命中的一天
原作:Noel Llopis
翻譯:King
2006年2月5日
轉(zhuǎn)載請注明作者和出處,如有商業(yè)用途請聯(lián)系作者kingcrimson at tom.com本文第一次發(fā)表在《游戲開發(fā)者》雜志的2005年就業(yè)指南上。
High Moon Studios 是游戲行業(yè)中一個不平凡的公司。我們的全部開發(fā)過程都使用了敏捷開發(fā)方法。特別是我的團隊,同時使用了Scrum(一種敏捷管理方式)和極限編程(一種敏捷開發(fā)方式)。這意味著我們要配對編程,測試驅(qū)動開發(fā),以及一切有爭議的實踐。我期望在未來幾年內(nèi),這些實踐將會變的更加尋常。
我領(lǐng)導(dǎo)著研發(fā)組(R&D),我們的首要職責(zé)是為不同項目的團隊提供技術(shù)支持。如今,這意味著按他們的步伐找出大量中間件,再選擇符合要求的去使用。但這也需要我們?nèi)ジ梢恍┛嗷睿瑸橐婧凸ぞ呔帉懘罅看a。
記住這一點,然后隨我來經(jīng)歷一個典型的工作日。
8:10 AM
我像往常一樣,騎車去上班。盡管我是只早起的鳥兒,但我們的一個程序員Jim還是比我要早到幾分鐘,并且已經(jīng)坐在辦公桌前了。
我快速的接收了一下電子郵件。同時我注意到PCLint在昨晚檢查我們代碼庫時捕獲了幾個小的warning。我很快解決了它們,并把代碼簽入。
8:20 AM
今天是周二,我們兩周的迭代會在周五結(jié)束。一個迭代由一段固定時間組成(我們團隊通常是兩周)。在這期間,團隊要根據(jù)客戶描述的需求交付一組可使用的功能。客戶(在這里是指公司內(nèi)部其他團隊)提出需求,并賦予它們優(yōu)先權(quán)。之后我的團隊會把這些需求拆分成若干任務(wù),并估計多長時間能夠完成它們(任務(wù)會在1到8小時之間變化)。
我和Jim來到了“戰(zhàn)爭室”(這間屋子的墻上貼著所有對應(yīng)用戶需求的任務(wù)卡片),并選擇了一個任務(wù)“混合ragdoll和動畫”。這個任務(wù)來自于用戶需求“把一個剛體扔到角色身上,能看到撞擊反應(yīng)”。這個任務(wù)早先估計能3小時完成,但是現(xiàn)在我們認識到ragdoll系統(tǒng)比我們預(yù)想的有一點復(fù)雜。于是我們重新估計了任務(wù)時間,定為4小時。
8:23 AM
在研發(fā)組的實驗室中,除了我們自己的工作區(qū)域外,還專門設(shè)置了配對編程的位置。每個位置擁有兩臺顯示器、兩個鍵盤、兩個鼠標、兩把椅子,以及容納兩個人的空間。我們所有產(chǎn)品的代碼都是由配對編程的程序員完成的。我和Jim隨便挑了個位置,開始工作。
自從采用測試驅(qū)動方法進行開發(fā)后,我們首先會為要實現(xiàn)的內(nèi)容編寫一個簡單的測試單元,之后再寫完整的代碼讓測試通過。在這個任務(wù)中,我們?yōu)榈谝粋€測試單元編寫了一個沒有輸入輸出的混合對象(Blender Object)。之后我們編寫了混合類(Blender Class),使測試通過。這只是一小步,但是方向是正確的。編寫測試單元、測試、重構(gòu),這整個環(huán)節(jié)只需5到10分鐘,并且我們反復(fù)的去重復(fù)這個環(huán)節(jié)。
8:39 AM
我們已經(jīng)實現(xiàn)了一小部分功能,并且所有的代碼都構(gòu)建并測試完畢,于是我們把它簽入到代碼管理(source control)中。這種方式被稱為持續(xù)迭代,要求程序員在代碼管理的最新版本工程中工作,并在一天里多次簽入自己的修改。
8:50 AM
其他的團隊成員陸續(xù)加入工作,占據(jù)了配對編程的各個位置。接下來我們互相做了簡短的溝通,明確我們各自的工作。

玩命工作……
9:37 AM
我無意中聽到Joel和Gary在討論他們?nèi)绾螠y試一些需要更新物理模擬的東西。我正好在幾天前做了這些,于是我加入他們的討論。我發(fā)現(xiàn)他們要做的一些工作是我之前已經(jīng)做過的,于是我?guī)退麄冋业轿覍懙臇|西,他們改動一下就可以使用。
10:05 AM
一切都進展的很順利。我們在早上就已經(jīng)簽入了四次。當(dāng)一個二人組工作正常時,他們在一天中會簽入20次或更多。照這個速度,我們比預(yù)先估計的四小時要提前完成。
10:14 AM
每天10點15分是我們的Scrum會議時間。我們?nèi)w聚集到戰(zhàn)爭室,準備開會。Scrum會議非常短,并且全體團隊成員只需站著開會(成員8人,再加上制作人Brian)。我們在屋里快速的走來走去,并開始討論目前的工作,讓所有人都跟上進度。
10:23 AM
會議中,出現(xiàn)了一個如何去讀取物理資源的問題。我們立即來到了配對編程區(qū)域,和與之相關(guān)的所有人展開討論。我們在白板上畫了一些簡潔的UML圖示,思考數(shù)據(jù)是如何傳送的。在十分鐘后,我們達成了一致意見,并返回各自區(qū)域繼續(xù)工作。
11:15 AM
我們的混合(Blending)工作的很正常。所有的單元測試都通過了,盡管我們還沒有把它用demo實現(xiàn)。因為還有一張任務(wù)卡需要一起來完成。我們馬上把代碼簽入。這些代碼顯然還有少數(shù)幾個地方可以改進,因為我們剛才集中在功能實現(xiàn)上,所以需要花些時間去重構(gòu)。我們進行了大量的單元測試,所以我們確信重構(gòu)不會導(dǎo)致任何bug。
11:56 AM
現(xiàn)在代碼處在一個更好的狀態(tài)中。我們把它簽入,并等待了幾分鐘,直到構(gòu)建服務(wù)器傳送回報告,所有內(nèi)容都構(gòu)建完成并測試通過。在這段時間內(nèi),我們討論了下一個任務(wù)如何進行。
12:05 PM
我們所有成員今天的工作進展齊頭并進,所以我和幾位團隊成員約定在午飯時間去上網(wǎng)。如果不上網(wǎng),我還可以去打籃球、騎車、跑步,甚至瑜伽。除此之外,還可以和High Moon工會的成員一起玩《激戰(zhàn)》(Guild War)。
1:10 PM
我回到辦公桌前,潦草吃了頓午飯,同時查看郵件(我在早上接收的,但因為一直在配對編程,沒有時間查看)。我讀了一封來自中間件開發(fā)商的郵件,關(guān)于我們早先的一個需求問題。我迅速發(fā)了回信。
1:25 PM
Sean來到我座位前。他正準備開始工作,但是上午與他配對的程序員被叫去處理Darkwatch的一些最后的問題。這個任務(wù)十分重要,優(yōu)先級高于我們在做的任何任務(wù)。
Sean迅速向我講解了他上午進行的工作,關(guān)于顯示我們物理系統(tǒng)的內(nèi)存使用狀況。我記得他們在上午的Scrum會議上提到過。我上一周也在為物理系統(tǒng)工作,所以我對代碼更熟悉一些。沒過多久,我們對任務(wù)已經(jīng)有了進展。

……玩命搖滾:)
2:07 PM
在編寫幾個測試單元并實現(xiàn)了一些功能后,我們準備把內(nèi)存顯示加入到demo程序中。幾分鐘后,我們在demo中顯示了物理系統(tǒng)使用內(nèi)存的狀況,并且測試在加入和移除剛體時,能顯示出高低變化。
但是出現(xiàn)了問題。當(dāng)我們移除剛體時,內(nèi)存使用沒有顯示降低。我們退出了demo,并且看到了一長串內(nèi)存泄漏提示。我們首先簽入了改動,然后跟蹤內(nèi)存泄露的代碼。這很可能不是由我們寫的代碼引起的,但是我們整個團隊遵照“代碼共享”原則。這意味著每個成員都可以在任何時候修改其他成員的代碼。
2:12 PM
構(gòu)建停止了!構(gòu)建服務(wù)器檢測到構(gòu)建失敗,并通過一個系統(tǒng)托盤程序提示我們。我打開了最新的構(gòu)建日志,看到release模式下一個單元測試失敗了。這時,坐在我們旁邊的Tyson說:“噢,我知道這是怎么回事。我正要去修改它呢。”不到半分鐘,他完成了改動并簽入代碼。幾分鐘后,構(gòu)建系統(tǒng)匯報構(gòu)建通過,一切重返正常。
2:17 PM
我們找到了內(nèi)存泄漏的地方,發(fā)生在一個引用計數(shù)的錯誤使用。我們先寫了一個測試單元顯示它的錯誤,然后在物理庫中修復(fù)了它。我們簽入了代碼。
2:18 PM
我們來到戰(zhàn)爭室,取下了一個任務(wù)。這個任務(wù)是要在demo里通過一個GUI,顯示出不同變量和函數(shù)的信息。我們登記了這個任務(wù),開始下一步工作。
3:43 PM
我們一直在待在配對編程區(qū)。我們近乎瘋狂的編寫測試單元和代碼,任務(wù)進展非常順利。在上一個小時中,我們?yōu)檫@個任務(wù)簽入了三次。
4:12 PM
另一對程序員在討論如何處理一些特殊情況的錯誤信息。這是一個重要的問題,并且應(yīng)該貫徹于所有代碼。我們開始了快速的討論,大多數(shù)團隊成員都參與其中。五分鐘后我們做出了決定,然后回到各自的工作中。
5:40 PM
我們進行了今天最后一次簽入。我們幾乎完成了這個任務(wù),但是還差一點。盡管我們可以再花一小時去完成它,但是我倆都非常疲倦,并且思路已經(jīng)不那么清晰,會犯一些錯誤。我們可以明天早上一來就繼續(xù)完成它。接下來是重要的部分,我們是否可以成功簽入。
我們團隊有一個規(guī)矩,任何人在下班時,不能簽入完就離開實驗室。你必須等待構(gòu)建服務(wù)器成功構(gòu)建代碼并且通過測試。我們保持短促的構(gòu)建時間,所以只需要再等待4到5分鐘。如果有任何地方崩潰,你就需要重新修復(fù)它。任何人沒有借口在構(gòu)建失敗時離開。
在等待構(gòu)建完成時,我查看了今天收件箱里積累的郵件。
5:44 PM
幾分鐘后,構(gòu)建服務(wù)器傳來成功的消息。今天是效率非常高的一天,照這個進度我們在周五就可以完成所有的用戶需求。聚集了各自成果的demo也逐漸開始顯得很酷。
敏捷開發(fā),特別是配對編程的一個特征,就是讓每一天都變得很緊湊。沒有小的空閑去閱讀郵件、瀏覽網(wǎng)頁,或者發(fā)呆。我們在一個工作日里完成了很多工作。但是我們不能在一天里長時間保持這個節(jié)奏,所以按時收工回家是很重要的。這使我能有時間在家閱讀技術(shù)書籍、構(gòu)思不同的想法,或者做次要項目的一些工作,或和家人在一起,享受其他愛好。
我登上愛車,朝家的方向駛?cè)ィ樕涎笠缰θ荨?/span>