※ 引述《chihyi1980 (喵球)》之銘言： : ※ 引述《iincho (..)》之銘言： : : PSP並不能代替資深工程師review，他只是提供一個量話指標讓你去評估自己程式的品質， : : 兩者並不衝突，很多時候必須要兩邊都一起做才能真正達到評估/提升程式開發人員的素質。 : : 最主要的不同點是，code review是為了提升軟體品質，不是拿來衡量程式員能力的活動。 : : 依我再某個專案運用PSP的結論，至少我可以大約估計我的LOC/bug是多少，比較容易分部在 : : 何種情境，單位時間的生產量是多少，準不準不知道，但是做為估計schedule的材料 : : 倒是蠻好用的。大部分的程式設計師都蠻抗拒自己的工作表現被量化，理由其實不外乎， : : 1.不了解 2.出來的數字很難看，尤其是很多時候所謂的資深程式設計師出來的數字..嗯嗯.. : 我想我這樣說吧...就像您所說的LOC/bug指標.. : LOC是什麼? Lines of Code.. 程式碼的行數..PSP裡面很常提到這個東東.. : 問題是LOC真的能夠代表生產力嗎? : 有人可以用一兩行解決問題..有人要用十幾行來寫... 這個問題，程式scale小的時候當然差異很大，可是程式scale大的時候呢? 我想LoC不見得會差到五六倍，而且單看LoC當然不準，可是混合其他指標一起看呢? 每多少行會出現一個bug難道真的沒有意義嗎? 我知道很多人會舉那種從幾千行code裡面找出幾十行來改的例子，可是就一個軟體產品 來說總不能全部的人都做這種事吧? 不然那幾千行程式誰來寫? PSP本來就是用來評估 一般程式員的基礎表現，它沒辦法評估超人一秒鐘可以繞地球幾圈。 軟體工程之所以會稱為工程，背後追求的就是可預測和穩定的產出，一個軟體降到 單兵的層級可以發揮的地方並不多，就算寫ACM這種比賽用的程式到最後也是套pattern， 我個人認為要量化並非做不到。 : 光是以前程序導向的語言要用LOC來估計單位時間的生產力..我就覺得有點難了... : 現在常見的物件導向語言又要怎麼能用LOC來估生產力呢? : 這是我覺得PSP的問題之一... : 另外就是.. : PSP希望程序員要自己作紀錄..程序員本身"每一分鐘在做什麼".. : 用此紀錄配合LOC來估計生產效率.. : 這是我認為更不合理的地方..每個人的能力與習慣都不同.. : 有人會一邊寫一邊改邊想.有人會通通想好了再開始coding... : 這兩種人可能實際產能相同..但估出來的單位時間生產力會相差甚遠... 關於這點嘛，其實大部分的人並沒有真的想過如何去增加自己的產量， 我指的不是把C/C++念得更熟之類的方法，而是在開發程式的流程上作改進。 做Record可以讓你找出自己的瓶頸在哪裡，這個部份人人不同， 至少有個依據知道自己寫程式最花時間的點在哪裡，總比抓瞎改強的多。 我們一直在說人家的方法不好，可是人家用這套方法已經上太空去了， 台灣還在原地殺豬公，可能真的要等三太子上身才有超英趕美的一天了。 : 我個人不反對一個程序員的生產力被量化.. : 但是評估的方式要正確才有用啊..不然只是浪費時間在做這些雜事罷了... : 舉個例子: 我之前的公司要求大家要配合CMMI, 要"詳細記錄"你每個時段所做的事. : 但是填寫這份報表的時間, 卻又不可以寫在每週工時內..搞到最後大家只能東拉西扯的 : 硬塞完這份表格... 這是執行面的問題，和方法不可混為一談。 : : 絕~~~對~~~不~~~要~~~拿這些數字來當績效評比的依據!!!! : : 所謂的程式設計師是地球上還算有點腦袋的一小部分生物，只要知道這些數字會被拿來 : : 當績效評比，保證最後看到的不是真正的數字，因為他們會作帳，比如說你會發現有些 : : bug永遠不會在帳面上出現..。 : : 拿來當自己程式設計能力的一個指標到是不錯的方式。 : 不要拿來當績效這一點我倒是相當贊同.. : --- : 抱歉,不是要戰你,只是針對PSP的作法有點意見... --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 211.76.240.242 ※ 編輯: iincho 來自: 211.76.240.242 (06/20 02:40) ※ 編輯: iincho 來自: 220.130.53.4 (06/20 09:46)