l

2014年9月22日 星期一

專業程式設計師怎麼做?(下)

Sep. 10 20:45~22:02

image

 

這一系列的最後一集,繼續介紹Bob大叔在《The Clean Coder》書中提到對於專業人士的建議。

 

做完的定義

每個開發人員心目中都有一份對於「工作做完」的定義,有些人認為程式沒有語法錯誤就算做完,甚至不管功能是否正確;有些人會手動測試,好一點的會會加上幾個單元測試;再負責任一點的,會請同事幫忙檢視程式碼。

Bob大叔任文專業人士的做完只有一個定義,就是做完表示程式碼完成並且可以通過所有的測試,QA和需求方也都已經認可。翻成白話文就是說:「產出可釋出品質的軟體才叫做完。」

這樣的高標準,的確是需要花費一番功夫方可達成。誰叫鄉民們是「專業人士」呢…是嗎?

 

整合失敗是一種Bug

有些團隊雖然實施「持續整合」(continuous integration;CI),但CI系統上經常有許多測試案例是無法通過的情況。不專業的團隊,會忽視建構失敗的警訊,將其視為惱人的噪音,或是歸因於「運氣不好」,錯誤下次應該會自動消失。久而久之,CI上可通過的測試案例越來越少,原本依靠CI所建構出的安全網也完全破功。沒有自動化測試與持續整合系統的幫助,軟體再度變成硬體,每次修改都帶來無止境的痛苦。

當CI系統上的專案建構失敗時,團隊成員應該立即停下手邊工作,一起排除問題。這個觀念Teddy覺得應該是從TPS的「安燈」作法而來,一旦代表問題的燈號亮起,生產線停止運轉,提高大家對於品質的重視。待問題排除之後,才可以恢復生產線運轉。

 

程式碼共享

不專業的程式設計師會將「自己」的程式碼鎖在保險箱中,不讓別人看見。自然地,他也不想去看別人的程式碼。程式碼不是地盤,程式設計師也不是黑道或小混混,不應在程式碼中畫地自限,阻擾知識的流通和讓更多雙眼睛一起幫忙找出問題的機會。

如果程式設計師只負責特定的程式碼,很可能會造成重複程式碼(duplicated code),當有人形成瓶頸的時候無人可幫助,例如短時間湧入大量工作、遇到無法克服的技術問題、對於一再重複相同的工作感到無趣、耍大牌、生病、請假、離職。

所以,Bob大叔認為專業人士應該採用XP的collective ownership(集體擁有權)實務做法,打破程式碼所有權之間的「派系之分」,程式碼的所有權應該屬於「整個團隊」所共有。

 

持續產品開發團隊

很多公司在執行專案的時候,採取以專案為主的方式來建構團隊。當專案成立的時候,到各個單位去拉人進來執行專案,每個人只在專案中停留短暫時間,甚至同時間屬於多個專案。待專案結束後這些人便歸建到原單位,因此很難培養默契。

Bob大叔說:「這是一種愚蠢的做法。」專業的開發組織會把專案交給已經具有默契且有凝聚力的團隊。這樣的團隊可以同時負責多個專案,團隊成員自我管理,依據各自的能力、意願、專長來分配工作,而且會順利完成所負擔的工作。

雖然Bob大叔沒有明講,但他在書中所敘述的團隊,就是Scrum團隊所具備的三點特性。

  • 跨職能團隊。
  • 自我管理。
  • 持續產品開發模式(維持有默契的團隊來完成各種專案)。

鄉親們,你們的團隊是屬於哪一種呢?

***

友藏內心獨白:Bob大叔的專業人士基本是就是敏捷開發人員啊。

沒有留言:

張貼留言