生命中的一天
原作：Noel Llopis
翻譯：King
2006年2月5日
轉載請注明作者和出處，如有商業用途請聯系作者kingcrimson at tom.com本文第一次發表在《游戲開發者》雜志的2005年就業指南上。
High Moon Studios 是游戲行業中一個不平凡的公司。我們的全部開發過程都使用了敏捷開發方法。特別是我的團隊，同時使用了Scrum（一種敏捷管理方式）和極限編程（一種敏捷開發方式）。這意味著我們要配對編程，測試驅動開發，以及一切有爭議的實踐。我期望在未來幾年內，這些實踐將會變的更加尋常。
我領導著研發組（R&D），我們的首要職責是為不同項目的團隊提供技術支持。如今，這意味著按他們的步伐找出大量中間件，再選擇符合要求的去使用。但這也需要我們去干一些苦活，為引擎和工具編寫大量代碼。
記住這一點，然后隨我來經歷一個典型的工作日。
8:10 AM
我像往常一樣，騎車去上班。盡管我是只早起的鳥兒，但我們的一個程序員Jim還是比我要早到幾分鐘，并且已經坐在辦公桌前了。
我快速的接收了一下電子郵件。同時我注意到PCLint在昨晚檢查我們代碼庫時捕獲了幾個小的warning。我很快解決了它們，并把代碼簽入。
8:20 AM
今天是周二，我們兩周的迭代會在周五結束。一個迭代由一段固定時間組成（我們團隊通常是兩周）。在這期間，團隊要根據客戶描述的需求交付一組可使用的功能。客戶（在這里是指公司內部其他團隊）提出需求，并賦予它們優先權。之后我的團隊會把這些需求拆分成若干任務，并估計多長時間能夠完成它們（任務會在1到8小時之間變化）。
我和Jim來到了“戰爭室”（這間屋子的墻上貼著所有對應用戶需求的任務卡片），并選擇了一個任務“混合ragdoll和動畫”。這個任務來自于用戶需求“把一個剛體扔到角色身上，能看到撞擊反應”。這個任務早先估計能3小時完成，但是現在我們認識到ragdoll系統比我們預想的有一點復雜。于是我們重新估計了任務時間，定為4小時。
8:23 AM
在研發組的實驗室中，除了我們自己的工作區域外，還專門設置了配對編程的位置。每個位置擁有兩臺顯示器、兩個鍵盤、兩個鼠標、兩把椅子，以及容納兩個人的空間。我們所有產品的代碼都是由配對編程的程序員完成的。我和Jim隨便挑了個位置，開始工作。
自從采用測試驅動方法進行開發后，我們首先會為要實現的內容編寫一個簡單的測試單元，之后再寫完整的代碼讓測試通過。在這個任務中，我們為第一個測試單元編寫了一個沒有輸入輸出的混合對象（Blender Object）。之后我們編寫了混合類（Blender Class），使測試通過。這只是一小步，但是方向是正確的。編寫測試單元、測試、重構，這整個環節只需5到10分鐘，并且我們反復的去重復這個環節。
8:39 AM
我們已經實現了一小部分功能，并且所有的代碼都構建并測試完畢，于是我們把它簽入到代碼管理（source control）中。這種方式被稱為持續迭代，要求程序員在代碼管理的最新版本工程中工作，并在一天里多次簽入自己的修改。
8:50 AM
其他的團隊成員陸續加入工作，占據了配對編程的各個位置。接下來我們互相做了簡短的溝通，明確我們各自的工作。
玩命工作……
9:37 AM
我無意中聽到Joel和Gary在討論他們如何測試一些需要更新物理模擬的東西。我正好在幾天前做了這些，于是我加入他們的討論。我發現他們要做的一些工作是我之前已經做過的，于是我幫他們找到我寫的東西，他們改動一下就可以使用。
10:05 AM
一切都進展的很順利。我們在早上就已經簽入了四次。當一個二人組工作正常時，他們在一天中會簽入20次或更多。照這個速度，我們比預先估計的四小時要提前完成。
10:14 AM
每天10點15分是我們的Scrum會議時間。我們全體聚集到戰爭室，準備開會。Scrum會議非常短，并且全體團隊成員只需站著開會（成員8人，再加上制作人Brian）。我們在屋里快速的走來走去，并開始討論目前的工作，讓所有人都跟上進度。
10:23 AM
會議中，出現了一個如何去讀取物理資源的問題。我們立即來到了配對編程區域，和與之相關的所有人展開討論。我們在白板上畫了一些簡潔的UML圖示，思考數據是如何傳送的。在十分鐘后，我們達成了一致意見，并返回各自區域繼續工作。
11:15 AM
我們的混合（Blending）工作的很正常。所有的單元測試都通過了，盡管我們還沒有把它用demo實現。因為還有一張任務卡需要一起來完成。我們馬上把代碼簽入。這些代碼顯然還有少數幾個地方可以改進，因為我們剛才集中在功能實現上，所以需要花些時間去重構。我們進行了大量的單元測試，所以我們確信重構不會導致任何bug。
11:56 AM
現在代碼處在一個更好的狀態中。我們把它簽入，并等待了幾分鐘，直到構建服務器傳送回報告，所有內容都構建完成并測試通過。在這段時間內，我們討論了下一個任務如何進行。
12:05 PM
我們所有成員今天的工作進展齊頭并進，所以我和幾位團隊成員約定在午飯時間去上網。如果不上網，我還可以去打籃球、騎車、跑步，甚至瑜伽。除此之外，還可以和High Moon工會的成員一起玩《激戰》（Guild War）。
1:10 PM
我回到辦公桌前，潦草吃了頓午飯，同時查看郵件（我在早上接收的，但因為一直在配對編程，沒有時間查看）。我讀了一封來自中間件開發商的郵件，關于我們早先的一個需求問題。我迅速發了回信。
1:25 PM
Sean來到我座位前。他正準備開始工作，但是上午與他配對的程序員被叫去處理Darkwatch的一些最后的問題。這個任務十分重要，優先級高于我們在做的任何任務。
Sean迅速向我講解了他上午進行的工作，關于顯示我們物理系統的內存使用狀況。我記得他們在上午的Scrum會議上提到過。我上一周也在為物理系統工作，所以我對代碼更熟悉一些。沒過多久，我們對任務已經有了進展。
……玩命搖滾：）
2:07 PM
在編寫幾個測試單元并實現了一些功能后，我們準備把內存顯示加入到demo程序中。幾分鐘后，我們在demo中顯示了物理系統使用內存的狀況，并且測試在加入和移除剛體時，能顯示出高低變化。
但是出現了問題。當我們移除剛體時，內存使用沒有顯示降低。我們退出了demo，并且看到了一長串內存泄漏提示。我們首先簽入了改動，然后跟蹤內存泄露的代碼。這很可能不是由我們寫的代碼引起的，但是我們整個團隊遵照“代碼共享”原則。這意味著每個成員都可以在任何時候修改其他成員的代碼。
2:12 PM
構建停止了！構建服務器檢測到構建失敗，并通過一個系統托盤程序提示我們。我打開了最新的構建日志，看到release模式下一個單元測試失敗了。這時，坐在我們旁邊的Tyson說：“噢，我知道這是怎么回事。我正要去修改它呢。”不到半分鐘，他完成了改動并簽入代碼。幾分鐘后，構建系統匯報構建通過，一切重返正常。
2:17 PM
我們找到了內存泄漏的地方，發生在一個引用計數的錯誤使用。我們先寫了一個測試單元顯示它的錯誤，然后在物理庫中修復了它。我們簽入了代碼。
2:18 PM
我們來到戰爭室，取下了一個任務。這個任務是要在demo里通過一個GUI，顯示出不同變量和函數的信息。我們登記了這個任務，開始下一步工作。
3:43 PM
我們一直在待在配對編程區。我們近乎瘋狂的編寫測試單元和代碼，任務進展非常順利。在上一個小時中，我們為這個任務簽入了三次。
4:12 PM
另一對程序員在討論如何處理一些特殊情況的錯誤信息。這是一個重要的問題，并且應該貫徹于所有代碼。我們開始了快速的討論，大多數團隊成員都參與其中。五分鐘后我們做出了決定，然后回到各自的工作中。
5:40 PM
我們進行了今天最后一次簽入。我們幾乎完成了這個任務，但是還差一點。盡管我們可以再花一小時去完成它，但是我倆都非常疲倦，并且思路已經不那么清晰，會犯一些錯誤。我們可以明天早上一來就繼續完成它。接下來是重要的部分，我們是否可以成功簽入。
我們團隊有一個規矩，任何人在下班時，不能簽入完就離開實驗室。你必須等待構建服務器成功構建代碼并且通過測試。我們保持短促的構建時間，所以只需要再等待4到5分鐘。如果有任何地方崩潰，你就需要重新修復它。任何人沒有借口在構建失敗時離開。
在等待構建完成時，我查看了今天收件箱里積累的郵件。
5:44 PM
幾分鐘后，構建服務器傳來成功的消息。今天是效率非常高的一天，照這個進度我們在周五就可以完成所有的用戶需求。聚集了各自成果的demo也逐漸開始顯得很酷。
敏捷開發，特別是配對編程的一個特征，就是讓每一天都變得很緊湊。沒有小的空閑去閱讀郵件、瀏覽網頁，或者發呆。我們在一個工作日里完成了很多工作。但是我們不能在一天里長時間保持這個節奏，所以按時收工回家是很重要的。這使我能有時間在家閱讀技術書籍、構思不同的想法，或者做次要項目的一些工作，或和家人在一起，享受其他愛好。
我登上愛車，朝家的方向駛去，臉上洋溢著笑容。