※ 引述《iincho (..)》之銘言： : ※ 引述《ricky906 (boy)》之銘言： : : 標題: [請益] 請問如何衡量一個programmer的能力 : : 時間: Tue Jun 19 12:50:29 2007 : : 想請教大家,如何來評估 : : 因為我覺得在軟体業實在是沒有一個量化的標準來評估 : : coding的時間嗎? 我也不覺得 : : code的效率嗎? 是很重要,但也好像不是唯一 : : 架構的設計嗎? 好像很難說 架構A 比 架構B 好3倍 : : 請問有什麼標準 or 量化的方式來評估自己 : : 謝謝 : : -- : : ◆ From: 220.135.40.166 : : → iincho:google://TSP/PSP 06/19 12:53 : : 推 PRAM:在時限內寫好程式的能力,以及適時向客戶say no的能力 06/19 13:35 : : 推 chihyi1980:老實說我不相信PSP估出來的東西.. 06/19 16:23 : : → chihyi1980:我寧可由資深工程師來對這個人做code review來準確些 06/19 16:23 : : → iincho:樓上,我覺得PSP還蠻準的啊.您有相關經驗可以分享嗎? 06/19 18:51 : : 推 leicheong:我想我也寧願自己看. 一個可稱為「具經驗」的programmer 06/19 23:44 : : → leicheong:寫的code往往可以看出一些減少出錯機會的pattern. 看得 06/19 23:46 : : → leicheong:夠多的話可以輕易看出那人是否曾經實作過一些正式的 06/19 23:48 : : → leicheong:專案的. 06/19 23:49 : : 推 ricky906:那如果沒有資深工程師可以幫忙review, 要怎麼自力自強 06/19 23:53 : PSP並不能代替資深工程師review，他只是提供一個量話指標讓你去評估自己程式的品質， : 兩者並不衝突，很多時候必須要兩邊都一起做才能真正達到評估/提升程式開發人員的素質。 : 最主要的不同點是，code review是為了提升軟體品質，不是拿來衡量程式員能力的活動。 : 依我再某個專案運用PSP的結論，至少我可以大約估計我的LOC/bug是多少，比較容易分部在 : 何種情境，單位時間的生產量是多少，準不準不知道，但是做為估計schedule的材料 : 倒是蠻好用的。大部分的程式設計師都蠻抗拒自己的工作表現被量化，理由其實不外乎， : 1.不了解 2.出來的數字很難看，尤其是很多時候所謂的資深程式設計師出來的數字..嗯嗯.. : 當然不是所有的資深人員都是這樣，如果單位有不錯的資深程式設計師，請他review可以 : 抓到蠻多PSP告訴不了你的東西，尤其是coding style這類，不過通常這些超人都忙著整 關於coding style這個問題, 我想在多請教一下, 曾經也有一位神人級的資深工程師這樣跟我提到 他說, 如果沒在coding style上下功夫, 那你有一半的時間都在debug 目前我對coding style的認知是 1. 一致的命名 2. 同性質的function放在一起 3. 利用assert來表達必然會生的事 請問有什麼參考的資料嗎 : 救地球，這時候可以用一些code inspection tool先掃過一次大概抓一下code的一些 : defect，我用過一些很貴的軟體，感覺還蠻準的，抓個五六成應該有。 : 用這些數字可以大致上抓出一個Programmer最基本的品質，再上去一點的架構方面到目前 : 還是沒有一個比較好的方式來評估好壞。 : 不過在量化之前，有個非常非常非常非常重要的一點: : 絕~~~對~~~不~~~要~~~拿這些數字來當績效評比的依據!!!! : 所謂的程式設計師是地球上還算有點腦袋的一小部分生物，只要知道這些數字會被拿來 : 當績效評比，保證最後看到的不是真正的數字，因為他們會作帳，比如說你會發現有些 : bug永遠不會在帳面上出現..。 : 拿來當自己程式設計能力的一個指標到是不錯 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 58.86.128.2 ※ 編輯: ricky906 來自: 58.86.128.2 (06/21 13:36)