XP編程中最大的謊言：客戶可以隨意變動需求

我原來的項目程序方 式看來就和XP差不多，當然pair programming做不到；但測試是完全做到了。至于說需求 變動，我認?是最不可能的地方。事實上，最經常碰到的故事是user story說了千百遍，大家都沒有異 義，甚至快速原型也做出來了，然後按這個開始開發，各模塊也測試得差不多了，甚至完成最後內部可
用性測試，但用戶一看到出來的樣子，馬上出一大堆新的需求，這也罷了，故事和原來是完全不一樣
的。要適應意味著要推倒重來。
其實傳統不傳統，XP不XP，最大的問題都不是開發開者測試，而是客戶的故事是未定型的。只要故事是 確定的，WINDOWS我也可以把它build出來。另一方面，客戶一邊情況下缺乏對需求的把握，所以常常是
拿幾籮框的界面菜單當成是需求，至于每個菜單?說什?，他自已是稀?糊塗的。要替他想出來，細化
出來。 所以問題就在這?，和編程無關的，就是用戶的需求分析，這才是關鍵。
少 了點什?，對不對？不錯！少了建模(modeling)。程序架構的建模當然是一個技術問題，用戶不需要懂，對用戶也是透明的，但是業務邏輯的建模，就純 粹是信息化中的業務問題，而偏偏這個建模，用戶不懂，不但不懂，而且最通常的情況是不願意懂，不願意承認它的存在（承認了就等于說自已業務能力不足了）， 結果，開發者實際上是拿到了一些無建模的“需求線索”，而常常在中國如此惡劣的軟件環境下，建模這一筆成本和時間，大約占了項目的五分之一左右，完全沒有 機會打入預算，除非，你不打算幹這行了。
在中國幹軟件幹得特別累人，這就是最根本的原因。在中國項目預算和時間都沒有辦法准確預計，這也是根本的 原因。.實際情況是時間都很緊，客戶並不了解開發程序需要非常詳細的故事定義，他認?這是技術的東西，他不需要懂；沒有准確的定義， 開發本身就存在著不到位的危險；時間就沒有辦法估計。沒有建模過程，所謂一個項目要花多少時間完全就取決于經驗，而且必須是完全同類同細節的經驗。這還沒 有包括開發者必須探求符合技術趨勢要求的開發和架構範式的所涉及到的不確定性。
上面兩條影響項目估計的最重大因素，在XP編程中都完全沒有涉及， 相信在國外成熟的軟件?業環境下開發者也極少會碰到。在這種條件下所謂推廣XP編程，等同于讓程序員背上不能背的責任，沒有建模過程，沒有成熟範式甚至甚 同類的經驗（不是缺乏開發經驗），卻要承擔所有預測不准的後果。既要馬兒跑，又要馬兒不吃草，莫過于此了。
所以ＸＰ說是可以適應客戶需求變化，我看只可能是專業性客戶，象軟件咨詢公司那種本來就是牛人的
需求變化。外國是這樣的，但中國不是這樣的。而且，在中國客戶可以按ＸＰ要求開發團隊適應客戶的
需求變化；但公司卻不會適應因此?生的團隊對工資和開發期限的變化。
缺 乏了需求階段性凍結這一條，ＸＰ是一堆讓開發團隊受難的屁話。ＸＰ最大的疑問是它的基礎，它假定客戶需求基本上是清晰的。而實際上傳統的經驗是無論你如何 和客戶一起商量故事，一直到你把東西做出來?止，客戶才會說那是不對的。這就是傳統軟件管理的基礎：客戶不知道他想幹什?，想要什?，直到他看到不想的， 他知道那是他不想要的，但仍不知道他自已到底要什?。ＸＰ編程說了一大堆擦邊球，都是廢話，因?這個最根本的東 西，他碰也沒有碰。
我是這樣看的。
XP編程有些理念值得參考，但所謂可以自由適應用戶需求變化的，沒有真正經受過地就不要站著說話不腰不疼??偏偏，無論是在美國的始倡者，還是在中國內地 的附和者，僅僅從其缺乏細節描述的高調中，我就認?他們都沒有經過那種地獄的磨練的。

對軟件項目中客戶的需求進行分級管理

客戶的需求是否應該得到滿足？軟件工程是否目的就是滿足客戶的需求？這個問題看來是無法加以回答的，因?，它沒有提供兩個基本的解釋，其一：客戶 的需求即算從客戶的利益立場出發，是不是合理的？其次，客戶的需求有多大程度上是必要的？還是只是一種個人的喜好？
如 果說對于商業客戶來說，在項目開始前，還存在著做與不做；以及多少價錢來做的選擇的話，那?，在許多情況下，工程人員如果不對此有明確的立場，唯一的結 果就是累死自已，而軟件項目永遠不令人滿意，也永遠不能完成。對于商業性客戶來說，客戶的需求是否合理是客戶自已的事情，客戶永遠是對的，這句口號的台下 詞是：只要客戶肯掏錢，那怕他要跳海，那也是他自已的事！但如果項目是已經簽署定的合同單，那?就存在著是否按原合同繼續，還是中止，還是變更付款條件的 的問題。而對于內部項目，所謂的成本就是工程人員有多累和什?時侯累死的問題。這時侯，軟件工程從業人員最好能夠明白，在自已累死以前，老板，以及那些不 學無術對技術一竅不通卻自以?是行?大家的同事，都不會對你有任何憐惜的。
所以這時侯那種無條件滿足客戶需求的工程需求管理就不適用了，這時侯， 軟件工程人員只能根據自已能夠承受的工作強度對各種需求進行取舍，而不是無條件地牽就“客戶”的需求，更不是遷就無知的需求。客戶是上帝這句話這時侯完全 不適用，因?客戶不會?朝改晚改的需求付錢，付帳的是程序員自已??讓自已早點累死。
把種種需求明列並分級是唯一的辦法；自已就按步就班一點點地 完成，這是唯一的辦法。事實上，對于商業客戶這也是適用的，因?收錢的畢竟是公司老板而不是項目組的程序員，公司老板收了錢就不管實際項目成本是多少而讓 程序員無條件接受客戶的需求也是常見的事情。所以把需求明列，既是讓老板明白眼前項目的成本到底是多少（老板通常是技術盲），也有了與客戶討價還價的根 據。
我把需求分成五個等級。五分等級也是工程技術上的常用方式，如同大學的五分制。
一級需求(或改變)是關鍵性的需求，這種需求如果不滿足，意味著整個項目不能正常交付使用，前期工作也會被全部否定。這是必須滿足的，否則就意味著否定程序員自已。所以定?Urgent.
二級需求（或改變）是後續關鍵性需求，它不影響前面工作內容的交付，但不加以滿足，新的項目內容無法提交或繼續。所以是NECESSARY；
三級需求是後續重要的需求，它不能滿足會令整體工作價值下降，?了體現項目價值，也是程度員自已的技術價值的證明，所以定?NEEDED;

以上三個等級是應該實施的，但時間性上可以作優先級的排列。
四級需求是改良性需求，沒有它並不影響已有功能的使用，但實現了，有可信的根據可以是BETTER。
五級需求是可選性需求，沒有它沒有誰會活不下去，有了它，沒有根據一定帶來好處，更多是一種設想，以及一種可能；通常只是需求代理人員的一種個人喜好。所以是MAYBE。

對于四級需求，工程人員項目有空，不妨做下去；對于五級需求，有興趣有余力就做，沒有興趣或者沒有余力，管他需求不需求，除非額外付大錢，就讓提這些外行需求的家?一邊涼快去。

http://frederick.blogdriver.com/frederick/703043.html

http://zwwwxy.blogspot.com/2005/05/blog-post.html
http://blog.csdn.net/zwwwxy/archive/2005/05/20/377147.aspx
http://zwwwxy.blogchina.com/1592465.html

技術角度看網站：Chinadaily,即將倒閉的網站

今天打算用一用那個中國日記網，結果發現這個網是一個joke。可以看出，這個網是一個不?中國國情也不懂網站開發的海龜投入大本錢找了幾個初級程序員閉門造車精心打造的博客網。?什?這樣說呢：

1. 這個網很熱心地在每一個博客頁中提供了一個mp3插入，大概是希望使用音樂增色吧，的確，也可以看出他在音樂上下了很大的功夫，包括允許用戶搞網上音樂 DJ。問題在于：音樂是這樣的東西，對于自已喜歡的音樂來說是音樂，自已不喜歡的就是噪音；音樂功能如果不是很容易地選擇放棄的話，只能起到轟客的作用。
2. 這個網使用asp/sqlserver，從4000字限制上看可能是oracle。實際上從使用上可以感覺到，它的真實的限制是4000字符，所以我覺得 是oracle的varchar2的限額。無論是oracle/sqlserver，它的特點都是事務可靠快速，處理文本是它的弱項，如果不能分到幾個單 列中的話，有經驗的程序員都是使用靜態文本連接代替把文章存入數據庫。而這個網的程序員連這條都不知道，結果這個博客日志提供了精美的編輯器，但卻是根本 沒有用的：使用編輯器意味著帶上大量的html字符，只要幾百個字的效果就不能再插入了。
3. 同樣的，它使用asp卻提供音樂編輯，這意味著極大量存儲和系統流性能，而這全是windows的弱項。
4. 使用asp建網，可以把網比較容易地建得精美，但是如果是博客這種網站，用戶不多的話這個網站要死，用戶稍多，這個網站仍然是要死??asp應付大流量，還是簡單流量的性能極差；維護成本非常高。其實，asp適合建造那些邏輯複雜而流量偏少的網站。

其他的就不一一列舉了。以上可知，這個網投資不少，但開發團隊的技術能力不足，尤其缺乏系統觀念，作?後進者沒有從基本業務模式上下功夫，卻希望通過一些小技巧提高檔次特色，而使用的技術又是原始的業余技術。正是典型的後進式網站燒錢建網到失敗的表現，
原文:

Jsp中的廣告服務器的模型規劃AdsServer

一、網站廣告的計費模式
一個網站的廣告服務器（Ads Server）模塊部分從業務模式上看，廣告服務器需要最少支持兩個計費模式：按時及按點擊次數計費。
對 于按發布時間計費，發布事件是很容易獲得的，難的是終止發布時間，假如沒有一個計時器的話。對于大量應用運行的服務器，鑒于資源消耗量的考慮，使用多線程 的計時器要慎重，毫無疑問，分散到模塊級自行決定計時器是低效而且危險的。如果是單一模塊中使用完整的計時器，也會令這個模塊的開發顯得過大，邊緣性的功 能占據了主要的開發工作；如果共用一個計時框架，那?就需要對已有的計時功能進行整體規則，令其使用新的計時框架，這實際上是一個升級。
即使是對于點擊次數的計費方式，發布時間計費仍是必須的，這與Googgle的廣告不一樣；後者沒有一個固定的頁面，也沒有固定的格式。而前者，卻有固定的地方，如果單純采用點擊計費，那?誰都希望放到首頁首欄，因?不點擊是不收錢的。

二、廣告欄目和廣告條目；
把 廣告位置(欄目)看作是一個廣告框，那?發布到這個框的廣告條目應該看作是廣告主的所有物，他是租用網站的廣告和相應的計費服務，發布自已的廣告，然後向 網站支付廣告費用。每一個廣告條目包括有廣告內容（發布代碼）；而每一個廣告欄目（位置）包括有價格信息和滾動設定，也即輪換廣告的設定，以及默認空白內 容。廣告條目與廣告位是一個多對多的關系，通過一個廣告條目訂單的實體實現聯系。
廣告條目定單是這樣的意思：每一個廣告條目可以發布到不同的廣告位（定單），以用將發面布多長的時間，多個訂單按先後順序排隊。這就意味著需要有一個雙向的廣告定單管理模塊存在。
廣告的發布實現是通過標簽完成。該標簽應用時需要包括如下屬性：廣告位ID，廣告條目ID。廣告位的ID把廣告標簽與廣告位置綁定，獲得廣告的價格和更替內容，以及發布時間；通過廣告條目ID獲得所要發布的的廣告內容。


三、網站管理者制定廣告欄目
廣 告欄目主要與費用相關，但不包含位置信息，這時侯與在那一個頁面沒有關系（那是由標簽使用決定），一般情況下與費用相關。位置信息只是它的一個提示屬性。 這樣，廣告位就可以不確定伴置地出現在“某類”伴置，同一個廣告欄目可以出現在不同的版面；而同一個版也可以出現多個廣告位置。所以，廣告欄目本質上也等 同于是版面廣告伴的集合。這樣的原因是由于無論如何定義廣告位置，最終都需要通過頁面的jsp代碼反應，既然jsp標簽本身與位置綁定，就不必在抽象層對 它進行細化管理了。這樣，可以省下管理員大量的工作。

四、廣告客戶制定廣告條目，並挂靠發布到具體單位、科室的各個廣告欄；
廣告 客戶對廣告條目的管理應用黃頁邏輯。自行管理其中的廣告內容，然後發布到某幾個廣告欄。不同的廣告欄有不同的（較低的）基礎發布費用，然後每次點擊就增加 一次點擊收費。每個廣告的表達方式大致包括顯示效果－》點擊鏈接－計數－轉向目標界面；顯示效果上是由廣告客戶自已管理還是由網站管理，還是有點未定論 的，大概最合適的方式是使用模板；iframe可以令效果代碼的錯誤不至于影響到發布版面的布局，同時目標代碼的下載不會影響主版面的顯示。總的來說，是 盡可能減小網站本身的管理要求，越是能夠達到這個目的，實際運行效果就越佳。

五、廣告欄目對廣告定單的處理；
廣告條目定單中帶有 發布時間的長短設定，發布事件可以輕易得到，這樣就可以在廣告欄目中得到一個該廣告定單有限期的起始和終止時間。廣告標簽對服務器時間的對照，確定該廣告 條目是否在有效期內，如果不是在有效期內，就把廣告條目清除，讀出下一條排隊的定單；如果沒有排隊定單，就拿出默認的欄目內容，並且把廣告欄目置?空閑。 這樣就不需要一個計時器了。

六、輪換廣告的實現
同一個廣告伴置按隨機性出現不同的內容，即出現不同 的廣告訂單，只有對需求強烈的廣告位置，既希望客戶能夠簽署較長期的定單，又不希望低價獨占最大潛在收益的廣告位置時，才真正適用。輪換可以看作是廣告欄 目本身帶有一個隨機轉換的方法。使用隨機數而不是時間段分割是肯定的，這樣算法較之使用時間段的分割顯得更高效也更簡單。
無論是使用一個帶機率分 享方法的輪換廣告伴置，還是幾個廣告預設欄隨機分享一個廣告位置，兩種抽象模型看來效果差不多。前者是在廣告欄目的屬性上設定，後者是在調用標簽上可以使 用多個欄目。相對而言，從維持廣告欄目一致性考慮，我傾向使用後一種邏輯。即在同一個欄目隨機分享的廣告欄目看作是不同的欄目，分別設定它的價錢，通過在 調用標簽上進行均分調用。

七、廣告模塊需要的開發工作總結：

1. 最少三個數據實體：廣告欄目、廣告欄目定單、廣告條目及其常規管理操作界面；
2. 一個計數轉向的cgi程序；
3. 廣告條目發布的jsp標簽；
4. 對廣告欄目的發布使用情況的統計界面；
5. 對廣告欄目定單的跟蹤界面；
6. 對廣告條目發布後的統計界面；

而套餐服務這?暫不包括，想不出它與核心模塊有什?必然的關系。　

http://blog.csdn.net/zwwwxy/archive/2005/05/24/380109.aspx

http://zwwwxy.blogchina.com/1642283.html