說實話，如何衡量一個工程師的工作量是一個非常難的事情。使用程式碼行數來衡量工程師的工作量雖然非常不嚴謹，但確實是一個比較容易量化的一個指標。

不過這個方法有非常嚴重的弊端，就是工程師們可以非常簡單的來拓展它的程式碼量。甚至改變一下程式碼風格，就可以提升不少。舉個例子，要寫一個簡單的判斷布林值並返回的函式，我們可以這樣寫：

function isBool (value) { return value === "love"}

上面 這是最簡單的寫法，但如果我們想要增加程式碼行數，科一這樣寫：

function isBool (value)

{

if (value === "love")

{

return true

}

else

{

return false

}

}

可以看到，非常簡單的，就把一個三行的程式碼程式設計了11行的程式碼。並且你不能說我做錯了什麼，因為這樣寫，程式碼確實更加容易閱讀。

實際上來說，這只不過是一些比較簡單的部分，而工程師們有一萬種方法，把他們的程式碼邊長，程式碼量翻個十幾翻完全是沒有任何問題。

除了在程式碼風格和邏輯處理方面，我們可以變化，我們還可以更換程式語言。比如，原來是用 Python 語言來編寫，現在還成 Java。本來使用 C++ 來寫，現在換成 C 來寫。

其實沒有什麼的。領導這麼幹，主要還是自己的能力有問題。上有政策，下有對策，我們無力改變領導，只能適應領導的愛好。

只要發給你的工資是真的，不就可以了麼？

1、有可能這位領導真心不懂，照貓畫虎

2、有可能團隊整體水平有限，必須量化

3、有可能是給領導的領導看的

你們領導不懂專業還是不懂思維？腦力勞動確實不能以數量為標準來參照工作量，這也是我說績效管理對注重教育和思維的工作沒有用處的原因。這種操作很容易陷入體制僵化和創新思維的困境。

1、工作量指標是個KPI，既然是KPI就是跟業績薪酬評價體系掛鉤了，他不能不對你的工資負責，因為專案資本總量在那，他要考慮怎麼分配這筆錢，還要能少花錢多辦事。

2、有些領導，說明不止一個領導，也就是說在一定範圍內管理層達成過共識，這個考核辦法簡單直接有效，省事省力好報告，畢竟敏捷很重要，精益也很重要。

3、這個管理場景也許是相對而言的，對比過往的非行數考核，bug更多，產生了更多更不好解決的問題的問題。

4、也可能是引入了諮詢顧問公司，做了調研後的解決方案。（或許是不成熟的解決方案，或許是試執行，看反饋再迭代。）

5、也許是真的，他們什麼都不懂。不過機率不高，他們能當上領導一般沒那麼傻，或許是一種培育專案團隊的秘密方法。

建議題主再觀察，看專案進度後，領導有什麼新舉措。也許每個階段都有不同的激勵手段。

加油，無論怎樣，都要看對自己的職業保障能否有價值就好了。

這種方式就是錯誤的，簡單的東西就這樣變得複雜了，東西多了失效的風險也就大了。應該相反，目標能達到，越簡潔越好！

把程式碼量化，我感覺真的很尷尬。一般一天的核心程式碼就那麼幾十行，如果這個給老闆看，老闆會覺得你一天沒坐什麼事，行數並不能衡量你實際做的工作，尤其是在不懂行的老闆手下。一般工作量都是以任務數來衡量的。

這個領導有些不靠譜，是不是沒有真正做過開發?

標準是什麼：實現一個功能，是程式碼越多越好，還是越少越好?

可能是公司要求他提供KPI標準，他覺得這可以作為考核之一。

你用專業的方式，嘗試跟他溝通一下。

因為領導不瞭解員工，瞭解之後，知道哪一個員工寫出的質量高，就會分開評價！

簡而言之，領導不是傻，而是懶！

對於一個程式設計師的工作效率，其實是沒有一個可以量化的數字指標的。有時候我們雖然出臺了很多的KPI考核細則，例如：Bug數量，完成率，任務量等等。但這些要麼很難能夠具現出來，要麼就需要花費較多的管理成本。

如果強制來實行這些考核的指標，到頭來可能花費的的管理成本都超過了程式設計師所提高的效率價值了。所以，一些小公司，資金本來就不是很充裕，如果還想對程式設計師進行考核的話，就只有暴力的使用程式碼行數來進行衡量了。

這就好像我們常常在提素質教育，但是最後還是用考試分數來說話一樣。因為素質教育的成果判斷太難了，最簡單的方式還是考試看分數。

當然，不同崗位的程式設計師，所寫的程式碼量也是不同的，例如：做業務邏輯的程式設計師，程式碼量肯定是超過做架構的程式設計師。但是，這不能說明架構就不行，這只是說架構很多時候是刪刪改改，總的程式碼行數提升不多。但是業務程式碼確是伴隨一直髮生的，程式碼量肯定就大。

所以，暴力的只是看程式碼行數，這種考核方式最後肯定也就只是一種擺設了。畢竟我們可以一個簡單的業務邏輯複雜化，從而提高程式碼的量。但是，這種方式對於系統來說並沒有好處。

例如：

return a > b ? a : b

我們判斷一個簡單的a b取最大的邏輯，一句程式碼，幾個字元就解決了。但是我們如果為了程式碼行數，我們可以寫成

if ( a > b ) { return a;}else { return b;}

這樣一代，一句程式碼變成了 6句，但是，多出來的這些行並沒有什麼價值。

因此，雖然考核程式碼行數是一種沒有辦法的辦法，但是絕對不是什麼好辦法。

是可以算是有點所謂量化的指標管理。不過個人感覺是一種粗暴管理，是不懂得程式設計的上司出的規定。這樣的管理反而出不了好的效果。

計科專業在軟體行業做過專案玩過產品，個人覺得如果一個領導能透過程式碼的行數來衡量一個程式設計師的工作量還算不錯的，如果遇到一個不懂技術在意識裡覺得技術都是一錘子買賣，遇到這種老闆那才是有理說不清那，所以程式設計師在工作過程中遇到什麼樣子的老闆決定了程式設計環境能不能長久呆下去。

衡量一個程式設計師的工作能力程式碼僅僅佔據很小的一部分，有過專案經驗應該都有一種體會真正耗費時間的地方在框架搭建功能需求分解過程，以及後續功能測試和真正程式碼的時間最多佔據百分三十，估計用不了，對於程式碼的沉重意識可能對於初學者來講比較沉重，老手更喜歡把時間都花在準備工作上，準備的越是充分工作就會顯得越輕鬆，很多程式設計新手覺得很奇怪，這些老傢伙平常不怎麼寫程式碼。都是看看這種資料，然後在書上比劃下，最後不知道什麼時間把程式碼就搞完了，然後就看見在拿著程式碼在除錯，有過幾年程式設計經驗的基本上都會有這種感覺，程式碼能力隨著時間推移都會學會，但有些東西不去修煉，隨著時間推移不會自然增長，比如演算法邏輯能力，架構能力。

“用程式碼行數來衡量程式設計的進度，就如同用重量來衡量飛機的製造進度”這是比爾蓋茨總結的一句非常經典的話，在現實中一個軟體工程師一天的程式碼量有100行就不錯了，但高質量的程式碼一天有20行就非常不錯了，所以程式碼的數量和質量比起來差距還是非常明顯的，一味的追求寫了多少行程式碼沒有多大本質意義，關鍵程式碼是不是真的能夠解決實際問題。

程式設計的本質是解決實際問題，不是一個炫耀技能的工作，也不是什麼排斥需求的過程，本質程式設計就是提升效率，做出產品讓大家生活的更加舒服，如果從這個格局出發，不在於有多少程式碼量關鍵還是要能解決實際的問題，程式設計的最終目的是解決疑難雜症問題。

作為一個程式設計師如何做出正確的選擇？

1.首先要確認自己目標和企業是一致的。目標一致的情況下很容易把排解掉一些不必要的矛盾，也就不要在意老闆是不是關心寫了多少行程式碼之類的事情了，無論什麼老闆最看重的是成效。

2.遇到不尊重技術的公司敬而遠之，不尊重技術在順風順水的情況下可能還沒有多大問題，在出現問題的情況很可能甩鍋給程式設計師了，不尊重技術的公司不會最後以技術為導向，技術的話語權都會低的可憐。

3.在任何企業混，作為一個技術人員，程式設計能力說到底是最關鍵因素。任何時候都不要忘記自身技術的積累過程，作為一個程式設計師技術才是立足之本。

作為一個程式設計師要懂得尋找一個尊重技術的公司，在這個公司找到合適的位置，並且無時無刻都不要忘記對技術知識的積累過程。

績效考核是企業對每一個部門和員工工作數量與質量的一種評估。各種工作崗位都有其特殊性，考核工作必須對各項工作都建立適用的量化標準。

從程式設計師的工作特性看，生產程式碼行數是考核他們工作最適合的量化標準。雖然這個標準還不足以考量每個程式設計師的工作質量，但程式設計師的工作質量並不是他們自己可以控制的，他們只能保證自己輸入的程式碼是嚴格按照架構師制定的語句原則和變數演算法原則輸入的，而在輸入時保證沒有輸入錯誤，起碼要保證在關鍵語句輸入時不出錯。只要能做到這些，程式設計師程式碼輸入量達到規定的行數或超額，就可以判定其績效考核成績合格或優秀。

績效考核工作最大的難度就是崗位量化原則的制定，有些崗位是無法用工作量來進行考核的，比如公關部門。對於這樣的部門只能透過在考核週期內，計算其目標工作任務的完好程度比，比例高於預定的值則為合格，低於這個值則為不合格或較差。

績效考核工作是對HR部門的挑戰，很多公司就是因為制定標準出了問題，而使績效考核工作流於形式，這是非常危險的一種現象。這將嚴重影響整個公司的工作效率，甚至嚴重削弱公司的核心競爭力，因為核心競爭力除了品牌固有的市場引導力和辨識度外，還包括企業文化戰略和人力資源戰略的有效性！

雖然沒有做過碼農，但是我之前一位領導最喜歡讓員工家裡有事的時候加班，他認為這是對工作最大的負責。

老闆喜歡不喜歡他大家不知道，但是幾乎所有能跟老闆說上話的人都在打壓他。

為什麼他現在還是領導？

因為我們這流行過年之後開除高層。

——領導把程式碼行數納入KPI的一個最大弊端，就是讓很多程式設計師把重心放在如何增加程式碼行數上來，而不是如何編寫高質量程式碼上，甚至會有人不惜一切代價用作弊手段換取程式碼量，大量複製貼上，完全不考慮複用，產生大量垃圾程式碼。

用程式碼行數衡量程式設計師的能力，是非常非常不靠譜的標準［靠程式碼行數來衡量開發程序，就好比用重量來衡量飛機制造的進度 -- 比爾·蓋茨說的］，一個良好的程式設計師應該有能力在一天寫的有效程式碼產出在200行以上吧，而且架構良好邏輯清晰。

我認為用程式碼行數來衡量程式設計師的工作量，說明領導根本不懂技術，外行指導內行。

如果要用程式碼的行數來判定我的績效，那我有很多種辦法獲得“優秀”：

在不影響程式碼正確性的前提下，多換行；方法引數有幾個，都可以換幾行；

每個方法，都寫上幾十行的註釋，循循善誘，娓娓道來；

多寫無用的類和方法，其中包含大量的程式碼，但是沒有其他地方呼叫它們；

終極大法，把第三方框架的原始碼拿出來引入到專案中，分分鐘幾萬行程式碼。

可以說，程式碼行數不能作為衡量程式設計師工作好壞的標準，一個大神程式設計師可能花費大量的時間在思考和設計，之後寫出寥寥數十行程式碼，達到的效果比一個程式設計師幾百上千程式碼好的多。如果非要用程式碼行數作為考核標準，程式設計師為了增加程式碼數量而忽視質量，廢程式碼增多，弊大於利。

那麼程式設計師的工作量改如何考核呢？個人覺得找到一個或一系列的標準還是很有困難的：

360度考核：就是從自我評價、同事評價、直屬下屬評價、直屬領導評價四個方面就行綜合考評；個人認為這種考核還是流於表面，形式大於實用。

我們現在的單位KPI標準是從多方面進行考察：需求上線率、程式碼檢測結果、單元測試覆蓋度、是否使用敏捷開發、是否使用自動化釋出等等，數十個打分項。雖然每個打分項都有應對的辦法，而且對需求開發難度沒有辦法衡量，不過總比統計程式碼行數要好很多。

現在很多IT公司使用OKR考核制度，不過OKR實際上並不是績效考核的工具，是不作為績效獎金依據的；個人傾向於使用技術KPI+個人OKR結合的方式，進行技術團隊的績效考核。

我發現，大部分單位技術人員的績效考核，直屬領導的意見實際上還是非常地重要的。所以我們在做好工作的同時，也要讓領導知道我們做了哪些工作，為團隊做了哪些貢獻。

領導知道，有個方便考評的指標很重要。程式碼行數就和搬磚的磚數一樣的方便統計。

但是領導不知道，程式碼不是搬磚。搬磚是移動已有物體，程式碼是寫出來的，就算是搬，也得需要知道搬哪塊，哪裡搬。

我們寫程式的正確姿勢，一般是按需求先粗略的實現出來，時間緊的話，通常都會出現大量的重疊程式碼或拖沓的程式碼，就是不停往上擼，所以叫擼程式碼，但是但凡水平高的人是不能容忍的，他會不斷的最佳化，比如重複的程式碼被重新包裝，一些複雜的過程被新的語法簡化等等，最後10000行的程式碼被最佳化為300行，為了執行效率，比如要用到移動手機上，於是由進行了壓縮，所有多餘的空格和註釋全被kill，只剩65行，結果領導說按程式碼行數發獎金，寫20000行垃圾程式碼的小屁孩拿了2000元，自己拿到6塊5毛錢，立馬一口鮮血噴了出來，上帝啊，救命啊，領導這個詞彙是誰發明的啊……

你們老闆是不是偶爾在哪看到了比爾蓋茨說的那句“用程式碼行數來衡量程式設計的進度，就如同用重量來衡量飛機的製造進度”了？

然後就真的拿到現實裡來應用？

這也太不現實了吧？？

正常工作中，一個程式設計師的工作量一天能敲出來四五十行可執行的程式碼就很不錯了！拿這個來衡量程式設計師的工作是否飽和或者是質量是否達到要求，那就是扯淡呢！

如果他真的把這個作為績效考核的指標，那我只能和你說：儘量往多了寫

1.註釋一句話斷成三句

2.對應的符號單獨一行

3.不同對應功能的區域程式碼中間多空幾行

如果不是直屬領導，不可能清晰知道你的具體工作量，只能大概知道你工作的內容，很宏觀的辦法，就是看你程式碼數量，因為如果不是技術大咖，一般都不會具體來分析你的程式碼質量，他們對你的考核是，功能是否完成，測試是否透過，不會在乎你具體程式碼質量。

如果產品功能也實現了，測試也通過了，上線執行也通過了，對領導來說，任務已基本完成，這時回頭在來看工作量，當然他會看程式碼行數，因為對他來說，你這麼行程式碼都寫出來了， 還會寫不出這行高質量找程式碼？答案是不可能。至於程式碼數量少，大部分都會認為，你要麼能力有限，要麼幹活偷懶，自然而然你考核就會低一點。因為領導不可能知道你所有乾的活，能知道大概也很不錯了。

如果這樣得話，就說明這個領導完全是個外行，或者是“半”外行。

我雖然不是IT人員，也不懂計算機程式設計，但我還知道程式碼就是程式設計、運算的步驟。說他完全是外行吧，好像有點冤枉他，因為他還知道程式碼；說他說“半”外行吧，他僅知道所列程式碼的行數越多 表明幹工作的多少，而完全不看實際的效果。真是令人可笑、可悲、無語、無奈！

這個領導可能不知道高斯一部把1加……100的結果是怎樣算出來的。你說，你要是用算式來考核的話，除了浪費紙張之外，還能說明什麼問題？領導啊領導，我不知道你是怎樣當上那個機構負責人的？還用如此低階和愚蠢的辦法來考核別人？