爭議的Pair programming
兩個人坐在一起programming:1. 明確說出自己的邏輯
2. 兩個人互相砥礪 (監視 XD)
3. 腦力激盪
爭議在於這樣是否浪費人力?是否有提高生產力?
結果一些研究證明,pair programming並沒有較好的生產力。
Single code base (不要有任何branch)
這在現今的工作環境應該很少見了,我想好壞處都有,可能case by case吧。Share Code (XP)
agile practices不建議讓code expertise只落在一個人身上,最好整個team都能了解。這個變成禍福與共,以及減低人員流動造成的斷層風險。
Optimization Last
這個common sense。Simplest Design and Refactor Often
這當然也是大家追求的目標Incremental Design
這個容易被誤解,他主要精神應該是“不要太快抽象化(abstraction)”,例如太快決定要用什麼design pattern,因為design pattern就是一個高階抽象思考的代表。為什麼不要太快抽象化?因為有個“優先採用最簡單設計”為前提的思考,然後看program如何演變再來打造,這也隱含了deliver first, refactor later的概念。不過批評者認為花時間做abstraction thinking才是一個好的programmer該有的特色,而且前期花的時間不會白費,當然deliver 時間會稍微晚一點 (相比於上段所描述)。
沒有留言:
張貼留言