Re: [請益] 請問如何衡量一個programmer的能力
※ 引述《iincho (..)》之銘言：
: 這個問題，程式scale小的時候當然差異很大，可是程式scale大的時候呢?
: 我想LoC不見得會差到五六倍，而且單看LoC當然不準，可是混合其他指標一起看呢?
: 每多少行會出現一個bug難道真的沒有意義嗎?
且不論是否要用來比績效了, 「好的」programmer和「壞的」programmer
寫出來的程式在相同功能的前提下長度本來就可以差很遠.
我的公司在三年前走了一個資深的, 請來了兩個剛畢業的代替. 那是
我也剛進這公司因此不太注意那邊的事情. (我們是不同team的.)
兩年間這code的長度由本來的10MB增加了一倍 (我們沒做業績考核類的東東,
因此可以相信這是他們正常情況下出來的長度) Database也「快高長大」
至接近2GB...
一年前因為一波辭職潮他們離開了公司, 老板又把那資深員工請回來了.
花了一年時間重整後, code的長度降至13MB, database容量降至1.2GB.
平常每天會出現十來次的database select deadlock victum的情況也
減至約半個月才一次.
因此新手和老手寫出來的code長度可以差很遠.
對「copy and paste(C&P)派」來說, 因為C&P前人的code可以增加長度
而且通常不會增加許多bug, 因此「bug per LOC」也不會高到那裡.
==
LOC那些甚麼的只是對正常狀態下的老手有意義, 而真的是老手的話
又不需要用LOC來量了, 因為只要露多少口風你得出來的LOC就完全
沒有用處, 你的source還會被弄至一團糟. 因為我傾向用人手管理
的方法.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 202.134.126.84
→
06/20 10:28, , 1F
06/20 10:28, 1F
→
06/20 12:17, , 2F
06/20 12:17, 2F
→
06/20 14:53, , 3F
06/20 14:53, 3F
→
06/20 14:54, , 4F
06/20 14:54, 4F
→
06/20 14:54, , 5F
06/20 14:54, 5F
→
06/20 14:56, , 6F
06/20 14:56, 6F
→
06/20 21:41, , 7F
06/20 21:41, 7F
→
06/20 21:41, , 8F
06/20 21:41, 8F
→
06/22 09:56, , 9F
06/22 09:56, 9F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 6 之 10 篇)：