第第頁程序員的工作不能用“生產效率”這個詞來衡量程序員的工作不能用“生產效率”這個詞來衡量

發(fā)表于：2023-09-04來源：外刊IT評論：不詳點擊數(shù)：標簽：效率

程序員的工作不能用“生產效率”這個詞來衡量。通過反復的交談，BillCaputo最終說服了我，讓我相信了一些不可思議的事情。這些事情改變了我整個看問題的方式，也讓我重新思考如何更好的工作。軟件開發(fā)中沒有“生產效率”。

通過反復的交談，BillCaputo最終說服了我，讓我相信了一些不可思議的事情。這些事情改變了我整個看問題的方式，也讓我重新思考如何更好的工作。

軟件（開發(fā)）中沒有"生產效率'。

幾乎正如10年前MartinFowler發(fā)現(xiàn)的，用生產效率來衡量軟件開發(fā)工作沒有任何意義。原因就在于，它們不屬于同一范疇。換句話說，生產效率不具有作為衡量軟件開發(fā)工作的適用性。"今天創(chuàng)造了多少代碼/軟件?'這是一個沒有意義的問題。即使可以這樣測量，軟件開發(fā)工作上的生產效率也不能以任何有意義的方式估計出它的商業(yè)價值。

這是因為，軟件開發(fā)這種工作并不一定非要生產出什么東西。讓我來舉個例子：比如說，碰巧有兩個程序員分別在開發(fā)兩個完全一樣的項目，他們在同一天被分配了相同的任務。第一個人，弗蘭克，回到電腦前，寫出了一個有1000行代碼的框架，完美的解決了問題。代碼規(guī)范書寫，全面（測試），有詳細的文檔描述部署和操作的流程。第二個程序員，皮特，轉身去了公園，在哪里，他一邊喂鴿子一邊思考問題。大概在下午4：45分，皮特溜達回辦公室，刪掉了200行代碼，并部署了他的修改問題就這樣解決了。

這兩個程序員，今天的"生產效率'誰的更高?答案是：這無關緊要。緊要的是，皮特解決了問題，同時為團隊消減了長期維護的成本。弗蘭克同時也解決了問題，但他因為生產了代碼，提高了維護成本，所以，(在其它方面完全等效的情況下)他的方案差一些。而把皮特稱作更有"生產效率'，則完全從實效性上扭曲了這個比喻。

我認為，優(yōu)秀的程序員，他所做的事情應該是去除問題。而相對的則是生產出什么。所以，技術上的生產產物，例代碼，文檔，數(shù)據(jù)等，對于實現(xiàn)"去除問題'的目標來說，都是必要但有害的。這就是為什么有時候，這最有效的解決方案是5分鐘的交流溝通。

對這種思考模式最有力的支持：當你用這種思維去看待軟件開發(fā)后，很多棘手的、能看得到但無法測量的問題突然間變得很容易理解。例如，為什么當程序員和他們的客戶隔離開時會顯得缺乏效率。難道讓他們避免打攪不會提高工作效率嗎?答案是不會，按常理這會使他們更有效率但也會造成他們更沒效率。因為他們的工作是為客戶解決問題，與客戶的隔絕導致他們無法找到問題，確定問題。相反，跟有問題的人保持溝通能更有效的解決問題，甚至有時候你一天8小時手指根本不需要碰鍵盤。

這將我們引向了另外一個問題：為什么軟件開發(fā)中維護成本相比起其它方面的成本顯得很難接受?為什么我們永遠無法在第一次做出"正確'的東西?一種解釋就是，軟件是一個對可能變化的問題的固定解決方案。當問題發(fā)生變化時(或我們對它的理解發(fā)生變化時)，問題和解決方案之間就出現(xiàn)了裂痕。這種隨著問題的演變而不停的修補產生的縫隙的活動代價高昂。這也解釋了為什么相對于其它軟件項目，（視頻）游戲通常的維護成本較低。這是因為它們需要解決的問題(讓人們去買這個游戲，玩這個游戲)基本上是根據(jù)人類心理學，而這是不常變化的。

好的程序員和壞的程序員之間10倍之差的"生產效率'又是從何說起?每個人都說這是事實，但事實上沒有人能直接的測評。我們的理論同樣能解釋這個問題。相比起工作效率來說，"解決問題'是一種更容易"調控'(金融詞匯)的東西，使得產生一個數(shù)量級差別的效果很容易實現(xiàn)。解決問題需要的是信息和洞察力。你要么有，要么沒有。不需要原材料，沒有生產能力限制。并不是差的程序員打字速度慢。并不是如果他們努力就能做得更好。他們是缺乏這種高效解決問題的眼界和必要的信息。也許無法測量好程序員和差程序員在生產效率上的差別的原因就在于沒有東西可測量。

還有很多現(xiàn)象都可以用這個理論來解釋。如果你去找，一定能發(fā)現(xiàn)一些。最近我一直在搜羅這方面的案例.試一試，看看這個理論是否也體現(xiàn)在你的工作中