我
原來的專案程式方式看來就和xp差不多，當然pair programming做不到；但測試是完全做到了。至於說需求 變
動，我認為是最不可能的地方。
事實上，最經常碰到的故事是user story說了千百遍，大家都沒有異 義，甚至快速原型也做出來了，然後按這個開始開發，各模組也測試得差不多了，甚至完成最後內部可
用性測試，但使用者一看到出來的樣子，馬上出一大堆新的需求，這也罷了，故事和原來是完全不一樣
的。要適應意味著要推倒重來。
其實傳統不傳統，xp不xp，最大的問題都不是開發開者測試，而是客戶的故事是未定型的。只要故事是 確定的，windows我也可以把它build出來。另一方面，客戶一邊情況下缺乏對需求的把握，所以常常是
拿幾籮框的介面選單當成是需求，至於每個選單裡說什麼，他自已是稀里糊塗的。要替他想出來，細化
出來。 所以問題就在這裡，和程式設計無關的，就是使用者的需求分析，這才是關鍵。
少了點什麼，對不對？不錯！少了建模(modeling)。程式架構的建模當然是乙個技術問題，使用者不需要懂，對使用者也是透明的，但是業務邏輯的建模，就 純粹是資訊化中的業務問題，而偏偏這個建模，使用者不懂，不但不懂，而且最通常的情況是不願意懂，不願意承認它的存在（承認了就等於說自已業務能力不足 了），結果，開發者實際上是拿到了一些無建模的「需求線索」，而常常在中國如此惡劣的軟體環境下，建模這一筆成本和時間，大約佔了專案的五分之一左右，完 全沒有機會打入預算，除非，你不打算幹這行了。
在中國幹軟體幹得特別累人，這就是最根本的原因。在中國專案預算和時間都沒有辦法準確預計，這也是根本的原因。.實際情況是時間都很緊，客戶 並不了解開發程式需要非常詳細的故事定義，他認為這是技術的東西，他不需要懂；沒有準確的定義， 開發本身就存在著不到位的危險；時間就沒有辦法估計。 沒有建模過程，所謂乙個專案要花多少時間完全就取決於經驗，而且必須是完全同類同細節的經驗。這還沒有包括開發者必須探求符合技術趨勢要求的開發和架構正規化的所涉及到的不確定性。
上面兩條影響專案估計的最重大因素，在xp程式設計中都完全沒有涉及，相信在國外成熟的軟體產業環境下開發者也極少會碰到。在這種條件下所謂推廣xp程式設計，等同於讓程式設計師背上不能背的責任，沒有建模過程，沒有成熟正規化甚至甚同類的經驗（不是缺乏開發經驗），卻要承擔所有**不准的後果。既要馬兒跑，又要馬兒不吃草，莫過於此了。
所以ｘｐ說是可以適應客戶需求變化，我看只可能是專業性客戶，象軟體諮詢公司那種本來就是牛人的
需求變化。外國是這樣的，但中國不是這樣的。而且，在中國客戶可以按ｘｐ要求開發團隊適應客戶的
需求變化；但公司卻不會適應因此產生的團隊對工資和開發期限的變化。
缺乏了需求階段性凍結這一條，ｘｐ是一堆讓開發團隊受難的屁話。 ｘｐ最大的疑問是它的基礎，它假定客戶需求基本上是清晰的。而實際上傳統的經驗是無論你如何和客 戶一起商量故事，一直到你把東西做出來為止，客戶才會說那是不對的。 這就是傳統軟體管理的基礎：客戶不知道他想幹什麼，想要什麼，直到他看到不想的，他知道那是他不 想要的，但仍不知道他自已到底要什麼。ｘｐ程式設計說了一大堆擦邊球，都是廢話，因為這個最根本的東 西，他碰也沒有碰。
我是這樣看的。
xp程式設計有些理念值得參考，但所謂可以自由適應使用者需求變化的，沒有真正經受過地就不要站著說話不腰不疼——偏偏，無論是在美國的始倡者，還是在中國內地的附和者，僅僅從其缺乏細節描述的高調中，我就認為他們都沒有經過那
種地獄的磨練的。
程式設計之美 尋找陣列中最大的K個數
從別人的那裡轉過來，這種題目，其實就是需要使用分治方法 程式設計之美上的尋找n個數中最大的前k數，給出了一種演算法，我認為比較好 演算法是這樣寫的 假設n個數儲存在陣列s中，我們從陣列s中隨機選出乙個元素x，把陣列分為兩部分sa和sb.sa中的元素都大於x，sb中的元素都小於x，這時，有兩種可能性 ...
迴圈圈中最大的數
如果把乙個正整數的每一位都平方後再求和，得到乙個新的正整數。對新產生的正整數再做同樣的處理。如此一來，你會發現，不管開始取的是什麼數字，最終如果不是落入1，就是落入同乙個迴圈圈。請寫出這個迴圈圈中最大的那個數字。請填寫該最大數字。注意 你提交的應該是乙個整數，不要填寫任何多餘的內容或說明性文字。無 ...
求陣列中最大的值
示例 求陣列 2,6,1,77,52,25,7 中的最大值 宣告乙個儲存最大元素的變數 max。預設最大值可以取陣列中的第乙個元素。遍歷這個陣列，把裡面每個陣列元素和 max 相比較。如果這個陣列元素大於max 就把這個陣列元素存到 max 裡面，否則繼續下一輪比較。最後輸出這個 max var a...