如何評(píng)價(jià)領(lǐng)導(dǎo)要用代碼行數(shù)衡量每個(gè)人的工作量？

我認(rèn)為用代碼行數(shù)來衡量程序員的工作量，說明領(lǐng)導(dǎo)根本不懂技術(shù)，外行指導(dǎo)內(nèi)行。

如果要用代碼的行數(shù)來判定我的績效，那我有很多種辦法獲得“優(yōu)秀”：

在不影響代碼正確性的前提下，多換行；方法參數(shù)有幾個(gè)，都可以換幾行；

每個(gè)方法，都寫上幾十行的注釋，循循善誘，娓娓道來；

多寫無用的類和方法，其中包含大量的代碼，但是沒有其他地方調(diào)用它們；

終極大法，把第三方框架的源碼拿出來引入到項(xiàng)目中，分分鐘幾萬行代碼。

可以說，代碼行數(shù)不能作為衡量程序員工作好壞的標(biāo)準(zhǔn)，一個(gè)大神程序員可能花費(fèi)大量的時(shí)間在思考和設(shè)計(jì)，之后寫出寥寥數(shù)十行代碼，達(dá)到的效果比一個(gè)程序員幾百上千代碼好的多。如果非要用代碼行數(shù)作為考核標(biāo)準(zhǔn)，程序員為了增加代碼數(shù)量而忽視質(zhì)量，廢代碼增多，弊大于利。

那么程序員的工作量改如何考核呢？個(gè)人覺得找到一個(gè)或一系列的標(biāo)準(zhǔn)還是很有困難的：

360度考核：就是從自我評(píng)價(jià)、同事評(píng)價(jià)、直屬下屬評(píng)價(jià)、直屬領(lǐng)導(dǎo)評(píng)價(jià)四個(gè)方面就行綜合考評(píng)；個(gè)人認(rèn)為這種考核還是流于表面，形式大于實(shí)用。

我們現(xiàn)在的單位KPI標(biāo)準(zhǔn)是從多方面進(jìn)行考察：需求上線率、代碼檢測結(jié)果、單元測試覆蓋度、是否使用敏捷開發(fā)、是否使用自動(dòng)化發(fā)布等等，數(shù)十個(gè)打分項(xiàng)。雖然每個(gè)打分項(xiàng)都有應(yīng)對(duì)的辦法，而且對(duì)需求開發(fā)難度沒有辦法衡量，不過總比統(tǒng)計(jì)代碼行數(shù)要好很多。

現(xiàn)在很多IT公司使用OKR考核制度，不過OKR實(shí)際上并不是績效考核的工具，是不作為績效獎(jiǎng)金依據(jù)的；個(gè)人傾向于使用技術(shù)KPI+個(gè)人OKR結(jié)合的方式，進(jìn)行技術(shù)團(tuán)隊(duì)的績效考核。

我發(fā)現(xiàn)，大部分單位技術(shù)人員的績效考核，直屬領(lǐng)導(dǎo)的意見實(shí)際上還是非常地重要的。所以我們在做好工作的同時(shí)，也要讓領(lǐng)導(dǎo)知道我們做了哪些工作，為團(tuán)隊(duì)做了哪些貢獻(xiàn)。

我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。