source: liquor.com

工程師的KPI — 淺談程式品質

Key Point Indicator (KPI)一直以來被廣泛應用在各行各業,然而,近年來有些聲音卻質疑他對公司的成效,甚至有些評論懷疑KPI其實對組織成長有嚴重傷害。當然,也有些人出面緩頰,指近年為數眾多的大公司,其沈淪並不全是KPI的錯云云。

當然這些不是本文重點,各位有沒有想過,身為程式設計師,你的績效應該要如何定義才公平?解bug數量?程式行數?完成專案數?

KPI究竟好不好?套一句我前老闆常說的:”Well, yes and no.” 在能得到結論前,首先我們恐怕得先看一些真實情況:


可以被明定的指標,就一定會被改善

對於領薪水的上班族來說,KPI跟績效與獎金呈現一定比例的關係,而人類這麼聰明,一定會想辦法提高KPI,以期得到更高的獎金。

然而,這隱含者一定風險。譬如,我們定義完成專案數越多的績效越高,那麼聰明的你,要怎麼快速提高績效?我想你一定不會想辦法提升自己能力吧?對,聰明如你,就知道要把每個專案都拆成三到四個小專案,KPI瞬間飆高。

我有一位極度聰明的同學,程式能力非常強,畢業後進到國內某手機廠工作,一段時間後向我抱怨,說他的主管約談他,表示他的成效不彰,他這才知道,原來公司的績效是以程式撰寫行數來評比的。這讓他大動肝火,因為他天天絞盡腦汁,就是為了寫出低耦合高內聚,易維護的好程式。結果這樣為公司付出,換來的是一個門外漢這樣無情的批評。他從此不再動腦,能copy-paste就copy-paste,能夠換行就換行,也不抽介面,所有設定都hard-code。當然,績效蒸蒸日上,每年都領超高獎金。

他領幾年轉飽就離職了。因為他知道這間公司沒有前途。果真後來應驗他的預言。

我曾經待過一個單位,隔壁team反其道而行,推行程式瘦身專案,凡是有勇氣動舊程式的人,為某特定肥大專案進行瘦身,計算個人為整體code set容量減少%數後,取前三名頒發可觀獎金。

這件事瘋狂異常,你知道第一名領走最高獎金的人做了什麼事嗎?他『勤奮地』把所有名稱較長的變數縮短,改用a、p、x等短名取代,當然對邏輯沒有影響,程式大幅瘦身。天知道這個原本就很難讀的巨肥程式被瘦身後會變得多恐怖…

不要懷疑,這麼荒謬如漫畫的情節,就真實在你我身邊發生。不信?看看你的周圍,那些不重視coding style,堅持己見,拒絕把自己邏輯正確的程式,改用一般較常見的方式撰寫的人,不是隨處可見嗎?


脾氣其實是不錯的指標

Clean Code的作者Robert C. Martin 在書中引用以下名句:

在業界看過這麼多大大小小的程式,當看到這張圖時,不禁大腿一拍:『對啊,就是這個!』簡直相見恨晚。如果這世上有個髒話感應器,或是憤怒值測量儀,那麼程式設計師的KPI可就好打多了!

可惜,這樣的儀器還沒有被量產。


說了這麼多,其實聰明如你已經發現了。這篇文章不是在講KPI要怎麼訂。我其實只是要奉勸各位軟體工程師:

你很討厭看人家寫得醜的程式,then don’t do that

你很討厭接手只有原作者看得懂的程式,then don’t do that

你很討厭人家用執行專案數來衡量你的貢獻,then don’t do that

要寫出好維護、好懂、好改的程式,確實是一門學問。如果真要以簡短的文字來說的話,那就肯定是『低耦合』、『高內聚』,與『適當的粒度』了。

我想我們可以另起專文與一些具體例子來介紹這三大原則,不過,那肯定不是今天了…今天就輕鬆聊完後,乾個杯吧!