一，
極限程式設計
極限程式設計
(extremeprogramming（xp
)是一套完整的涉及軟體開發各個方面的開發觀念，這裡擷取編碼相關部分。
1.組隊程式設計（
pairprogramming
） xp
中，所有的代
碼都是由兩個程式
員在同一臺機器上一起寫的——這
是xp中讓
人爭議最多、也是最
難實施的一點。這保
證了所有的**、
設計和單元
測試至少被另乙個人複核
過，**、
設計和測試的
質量因此得到提高。看起來
這樣象是在浪費人力
資源，但是各
種研究表明事
實恰恰相反。
——這種
工作方式極大地提高了工作
強度和工作效率。
在實際工作中，你的老闆可能不會同意你這麼幹，我們可以考慮乙個變通的實現方法。在專案中，總會存在大量類似的工作，將這個工作安排給至少兩個人以上共同承擔，這些人為一組，在複核的時候互換角色。同樣可以在一定程度上達到目的。這樣做複核人員對自己所要複核的內容比較熟悉，可以保證工作質量與效率，同時每一項任務至少有兩個人以上對其熟悉，這樣在出現人員生病，離職等等調整的時候，專案經理不會因為某一位團隊成員的變動，而對整個專案造成難以平衡的影響。專案
開發中，
每個人會不斷地更換合作
程式設計的夥伴。因此，
pairprogramming
不但提高了軟體
質量，還增
強了相互之間的知
識交流和更新，增
強了相互之
間的溝通和理解。
這不但有利於個人，也有利於整個專案、
開發隊伍和公司。專案經理在做好專案的同時，已有責任與義務，為公司培養優秀的人才。而更多優秀的人才，會使你的工作變得輕鬆。2．
測試驅動開發反饋
是xp的四個基本的價
值觀之一——在
軟體開發中，只有通
過充分的
測試才能
獲得充分的反饋。
xp中提出的
測試，在其它軟體
開發方法中都可以
見到，比如功能測試、
單元測試、系
統測試和負荷
測試等；與眾不同的是，xp將
測試結合到它獨特的螺旋式增量型
開發過程中，
測試隨著專案的
進展而不斷
積累。另外，由於
強調整個開發小
組擁有**，
測試也是由大家共同
維護的。即，任何人在往代
碼庫中放程式（
checkin
）前，都
應該執行一遍所有的
測試；任何人如果
發現了乙個
bug，都
應該立即為這個
bug增加乙個
測試，而不是等待寫那個程式的人來完成；任何人接手其他人的任
務，或者修改其他人的**和
設計，改
動完以後如果能通過所有
測試，就
證明他的工作沒有破壞願系統。
這樣，測試才能真正起到幫助獲得反
饋的作用；而且，通
過不斷地優先
編寫和累積，
測試應該
可以基本覆蓋全部的客戶和
開發需求，因此開發人
員和客戶可以得到盡可能充足的反饋。
3．重整和優化
(refactoring)
xp強調簡單的設計
，但簡單的設計
並不是沒有
設計的流水
賬式的程式，也不是沒有
結構、缺乏重用性的程式設計。
開發人員雖然
對每個userstory都進
行簡單設計
，但同時
也在不斷地
對設計進行改進
，這個過
程叫設計
的重整和優化（
refactoring）。這
個名字最早出現在
martinfowler
寫的《refactoring:improvingthedesignofexistingcode》這
本書中。 refactoring
主要是努力減少程式和
設計中重複出
現的部分，增
強程式和
設計的可重用性。
refactoring
的概念並不是xp首
創的，它已
經被提出了近
30年了，而且一直被
認為是高
質量的代
碼的特點之一。但
xp強調
，把refactoring
做到極致，應該隨
時隨地、盡可能地進行
refactoring
，只要有可能，程式設計師都不
應該心疼以前寫的程式，而要毫不留情地改
程序式。當然，每次改
動後，程式設計師都
應該執行
測試程式，保證新系
統仍然符合
預定的要求。 1．頻
繁地整合，集體擁有代
碼（collectivecodeownership），編
程規範 xp開發小
組經常整合不同的模組。
為了提高軟體
質量，除了
測試驅動開發
和pairprogramming
以外，xp要求每
個人的代
碼都要遵守程式設計
規範，任何人都可以修改其他人寫的代
碼，而且所有人都應該主
動檢查其他人寫的**。
頻繁地整合（
integration
） 在很多
專案中，開發人
員往往很
遲才把各個模
塊整合在一起。在這些
專案中，開發人
員經常在整合過程中
發現很多
問題，但不能肯定到底是
誰的程式出了
問題；而且，只有整合完成後，開發人
員才開始稍稍使用整個系
統，然後就
馬上交付給客
戶驗收。對於客
戶來說，即使這些系
統能夠通
過終驗收
測試，因為使用
時間短，客
戶們心裡並沒有多少把握。
為了解決這些
問題，xp提出，整個專案
過程中，
應該頻繁地，盡可能地整合已
經開發完的
userstory（每
次整合乙個新的
userstory）。每
次整合，都要執行相應的
單元測試和
驗收測試，保
證符合客戶和
開發的要求。整合後，就
發布乙個新的應用系
統。這樣，整個專案
開發過程中，幾乎
每隔一兩天，都會
發布乙個新系統，有
時甚至會一天
發布好幾個版本。通過這個
過程，客
戶能非常清楚地掌握已
經完成的功能和
開發進度，並基於
這些情況和開發人
員進行有效地、及
時地交流，以確保專案
順利完成。 集體擁
有**（collectivecodeownership
） 在很多專案
開發過程中，開發人
員只維護自己的代
碼，而且很多人不喜
歡其他人隨意修改自己的代
碼。因此，即使可能有相應的比
較詳細的
開發文件，但乙個程式
員卻很少、也不太願意去
讀其他程式設計師的代
碼；而且，因
為不清楚其他人的程式到底
實現了什
麼功能，乙個程式
員一般也不敢隨便改
動其他人的**。同
時，因為是自己
維護自己的代
碼，可能因
為時間緊張或技術
水平的侷限性，某些
問題一直不能被
發現或得到比
較好的解決。
針對這點，
xp提倡大家共同擁有代
碼，每個人都有權利和
義務閱讀
其他**，發現
和糾正錯誤
，重整和優化代
碼。這樣，
這些**就不
僅僅是一兩個人寫的，而是由整個專案
開發隊伍共同完成的，
錯誤會減少很多，重用性會盡可能地得到提高，代
碼質量是非常好。
為了防止修改其他人的代
碼而引起系統崩
潰，每個人在修改後都
應該執行
測試程式。（從
這點，我
們可以再次看到，
xp的各個慣例和
規則是怎
樣有機地
結合在一起的。） 程式設計
規範 xp開發小組
中的所有人都遵循乙個統一的
程式設計標準，因此，所有的代
碼看起來好像是乙個人寫的。因為有了
統一的程式設計
規範，每個程式
員更加容易
讀懂其他人寫的**，
這是是實現collectivecodeownership
的重要前提之一。
PM見習手冊 章5,6,7
一，資源管理 資源管理包括人，軟體，硬體1 人 乙個人，什麼時候到你的專案的，什麼時候出去的，在你的專案中的時候表現如何，優點在 缺點在 他的聯絡方式，當前的主要技能等等，需要你去了解，記錄下來。當你評價你的乙個員工，你只能說出來他好，不好，而不能說出來好在 不好在 那麼很顯然，你無法很好的使用這個...
程式設計珠璣第九章
1 記憶體訪問 連續記憶體訪問與跨頁面訪問記憶體的區別 注意在訪問記憶體的時候，要注意記憶體的連續性，如果訪問的記憶體不是連續的，那麼程式的執行速度也會受到極大的影響 例如訪問乙個二維陣列時，先訪問行，再訪問列，能夠減少頁面排程次數，同時cache命中率也相對高些。2 遞迴呼叫巨集時，需要小心，巨集...
《敏捷軟體開發》第二章極限程式設計實踐
作為開發人員，我們應該記住，xp並非惟一選擇。pete mabreen 2.1極限程式設計實踐 極限程式設計 extremeprogramming，簡稱xp 是由kentbeck在1996年提出的。kentbeck在九十年代初期 與wardcunningham共事時，就一直共同探索著新的軟體開發方法...