Re: [請益] 請問如何衡量一個programmer的能力
※ 引述《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)
討論串 (同標題文章)