乙個令人震驚的事實是連生產率這樣的常見度量資料都沒有乙個簡單的定義。連我們日常經經常使用到的公式：生產率=工作產品/工作量（工作產品能夠是**行，功能點，也能夠是不論什麼能夠計數的東西。比方文件頁數）都是錯誤的。
假設你正常嘗試使用生產率做度量，那麼至少應該先分為以下兩種度量資料。
注意以下的樣例為了便於理解使用的是**行，但實際上這兩個概念是ifpug（國際功能點使用者組）對功能點計數時做的分類。
以下這段對話將產生乙個應用類度量資料：
a：「這個軟體有多少**行？」
b：「等我數一下……10000行」。
a：「多少人天開發出來的？」
b：「大約100人天吧」
a：「那麼生產率=10000行/100人天=100行/人天」
三個月後……
b：「我們又改動了一些**，新增了一些**，可是也刪除了一些**」
a：「哦？」
b：「多投入了100人天，只是如今還是10000行。」
a：「那麼如今的總生產率是：10000行/200人天=50行/人天；假設僅僅算二期麼……0。我也幫不了你了」
b：「好吧……二期算是白忙一場」
a：「這個軟體有多少**行？」
b：「一共同擁有兩期……等我數一下……第一期100人天開發了10000行……第二期也是100人天，新增2500行，刪除2500行，改動5000行」。
a：「那麼一期生產率=10000行/100人天=100行/人天」
b：「二期呢？」
a：「二期生產率=（新增2500+刪除2500+改動5000）/100人天=10000行/100人天=100行/人天」
b：「yeah!「
a：」只是。也有的體系說二期生產率=（新增2500+刪除2500/2+改動5000）/100人天=8750行/100人天=87.5行/人天
b：」啊？「
a：」等下……還有體系說二期生產率=（新增2500+刪除2500/4+改動5000/2）/100人天=……這個，你自己算吧。
b：」好吧。總算比白忙一場好。
由於增刪改都要花費工作量，所以用開發類資料做計畫和考核更加公平一些。
只是，一般採用功能點更加合理一些。比方在重構中極有可能刪除大段的**（我們以前在15分鐘左右把4000行**重構為55行，功能不變）。而實際上應用的變化並不大。假設用這樣的外界（客戶。高層）難以感受到的「變化」來做度量元，非常難得到認同。
三種體系（增刪改權值同樣，或/2。或/2/4）選擇哪個好呢？
我也不知道，由於這三種體系都有人在用。我的建議是：
1. 假設剛剛開始做度量
隨便選擇乙個方法就好了，可是請記錄下原始資料。
也就是說。要記住有多少新增，多少刪除，多少改動。
2. 資料積累比較多了
請按三種方法都計算一次，然後對照一下計算結果和實際工作量的相關係數（相關係數日後會科普一下。excel表裡變有這個函式correl(b1:g1,b2:g2），相關係數越高表明用這樣的方法做估算更接近事實。
度量分析沒有「理論上哪個最好」，僅僅有資料本人才有發言權。
或者說。度量分析的本質就是消除各種理論的主觀性、片面性、理想化，把發言權留給資料本身。
所以自己做資料分析是免不了的事情。
只是，不論有多少理由，乙個軟體僅僅改動、刪除功能而不新增功能。都不是乙個正常的事情。
過多改動功能表明需求分析最初做的不好。而刪除功能則表明做了過多的無用功能。
為了約束團隊，防止他們把「改軟體」當作工作，須要定期監控兩者的比值：應用類/開發類。假設這個資料不斷下降。表明大家都在改動之前的功能，非常久沒有大量新增功能了。
在小而美的產品研發中，改動功能可能是乙個常態，但這不能作為開始能夠不深入思考「最佳功能」的理由。
在專案開發尤其是外包專案中。僅僅改動而不新增功能是乙個災難，由於客戶多數時候不會為改動功能付費，他們覺得這是由於乙方未能深入分析需求造成的。
也就是用多少**能實現多少功能的問題，編碼有效性越高，則所需**越少。（日後有具體文章描寫敘述）
當然，這裡的「功能」指國際標準功能點度量出來的功能，而不是我們平時所說的「個人理解不同規模也不同」的那種直覺功能。
在這樣的場景中，應該使用：編碼有效性=總**行/總功能點數=總**行/應用類功能點數。
比方在之前那個樣例中，第二期**行可能還是10000行，可是假設功能點新增了，那麼編碼有效性實際上增高了。
以下是乙個功能點、**行、編碼有效性、應用類、開發類資料的完整應用場景。
a：「這個軟體有多少**行和功能點？」
b：「一共同擁有兩期……等我數一下……第一期100人天開發了10000行。200功能點……第二期也是100人天。新增2500行，刪除2500行。改動5000行；新增50功能點，刪除20功能點，改動30功能點」。
a：「那麼一期**行生產率=10000行/100人天=100行/人天，功能點生產率=200功能點/100人天=2功能點/人天」
b：「二期呢？」
a：「二期生產率=（新增2500+刪除2500+改動5000）/100人天=10000行/100人天=100行/人天。功能點生產率=（增50+刪20+改30）功能點/100人天=100功能點/100人天=1功能點/人天」（臨時僅僅用第一種增刪改權值演算法）
b：「哪期專案做得快呢？「
a：「從**行看，一樣；從功能點看，一期專案快一倍。
b：「以哪個為準好呢？」
a：「功能點好，比較easy給客戶和領導交代」
b：「二期真爛。
a：「也未必，你們的編碼有效率提公升了。
b：「怎麼講？」
a：「二期完畢後（不是二期開發本身），整個產品還是10000行。功能點卻新增為300。你們如今的**效率已經達到10000/300=33行/功能點了（越低越好。一期是10000/200=50）」
b：「生產率減少。編碼有效性提高……怎麼做總體評價呢？」
a：「生產率提高是終極目標。只是編碼有效性的提公升有利於未來的生產率和質量的提公升。所以。如今總體評價是生產率下降了，未來要看你們以後能否真正發揮編碼有效率的優勢了。」
怎麼樣？假設是我，假設能寫乙個由數字組成的專案報告。我才不會寫一大堆模稜兩可的文字呢。
RCP應用程式開發之二 核心類總結
上次講述了怎麼新建乙個rcp應用程式，沒有對其核心的類總結。今天晚上抽空簡單的總結了一下,主要包括針對 在eclipse3.0版本新建的rcp應用程式中有三個核心的類 2 iperspectivefactory的實現類perspective，在前面講到，perspective是eclipse工作台所...
類和物件總結（之二）
size small size 上一次的總結，我談到的是對類和物件兩個基本概念的理解，包括類的定義 在物件導向程式設計中的意義 格式 屬性的宣告 普通方法的定義 物件的例項化。然而，其實對於類和物件理解，我卻認為是乙個無窮盡的過程，它會隨著我們對專業知識的了解加深 專案經驗的積累而厚重。今天，在此，...
PHP中類的理解和應用 二
許多php 的愛好者在學習過程中感到對php 中類的概念較難理解和掌握，雖然知道類既然存在就有其存在的道理，但是由於平時接觸和使用的機會較少，也就一略而過。其實，只要我們理解變數和函式這些php 基本概念的話，掌握類的含義就不成問題。鑑於類在php 的重要作用，本文將結合具體事例介紹php 中類的概...