[[332751]]

 在知乎上有這樣一個問題“為什么美國程序員工作比中國程序員工作輕松、加班少?”，問題描述如下：

感覺美國程序員工作時間靈活、加班少，相比與國內程序員工作，似乎壓力小很多。但是美國程序員的產出卻非常牛逼(如google、fb等)。難道是因為他們效率更高嗎?如果是，國內程序員是否能提高效率減少加班和壓力呢?

下面這個來自“invalid s”的回答獲得近萬個贊，一起感受一下吧。

01

是的，他們效率更高。

但是，國內程序員不可能通過提高效率減少加班和壓力。因為這事的決定權不在你而在公司。

之前“開發和產品經理因為識別手機外殼顏色而打架”的傳聞之所以能引起廣泛共鳴，就是因為這類事實在太普遍了，太多人感同身受。

因為中高層傻。

所以，當你花大力氣設計了一個精簡高效的架構，把一個很難的問題干凈漂亮解決掉時，絕不會有人擊節贊嘆——恰恰相反，他們覺得你搗鼓了個把月才產出幾百行代碼，反而會犯嘀咕：這人是磨洋工呢，還是不會?

你面向搜索引擎編程，亂七八糟拷一大堆東西到代碼里，用到用不到都留著，KPI表現反而會特別亮眼。

一天幾千行代碼當然亮眼。

一群外行，怎么會知道這幾千行里面就兩行有效呢。

02

類似的，你兢兢業業，一個bug都不讓出，人家就把你忘了;反之，你大大咧咧，一個功能你能寫出800個bug——經理看起來就很忙很努力，因為他得不停的和你交流;你也很忙很努力，不停跑經理那里討論問題：全公司你最忙你經理最敬業，不獎勵你倆還有天理嗎?!

你看，你好我好大家好，身為聰明人，你為什么不多寫點bug呢。

當然了，這是極端情況。大多數公司還是沒這么極端的——他們的中高層還不是純2X。

即便如此，他們中的絕大多數——包括多數程序員——仍然不懂軟件工程。

他們并不知道，或者說并沒有想過，今天你寫的每一行代碼，都會是明天的新代碼的地基。

即使你知道，也沒辦法讓中高層明白。

如果你今天寫的太過隨意，明天就很難在這個基礎上擴展它;如果你著急完成任務，今天不先把昨天的設計缺陷修改掉，而是想一個辦法繞開……那么明天你就不得不繞著圈子躲開更多問題。

越往后，就越難改;越難改，就越容易出bug。

但是，如果你想改昨天的代碼，你就得先解決前天的問題;想解決前天的問題，大前天乃至大半年前的設計缺陷你就得逐一解決掉。然后，這大半年里，你就完不成任何新提的需求。

反正至多做三兩年我就要換工作了。隨他去吧，完成眼前的工作要緊。

因此，為了急功近利的眼前效率，中國程序員的長遠效率自然變得極低——越往后越低。

03

我曾經接過一個任務。

因為高層設計的嚴重問題，我們不得不在網絡通信層去更新用戶登錄狀態(稍微懂點的都知道這需求有多奇葩：打個比方的話，這就好像讓發動機制造商在活塞上做一個閥門以便隨時泄壓一樣怪異。原因是我們的整車商忘了裝啟動機也沒有離合器，所以需要減輕發動機阻力方便人家把車推起來)。

項目經理不懂。他覺得一條SQL語句也就是0.0x秒的事，我們的流程耽誤1秒問題應該不大，所以就答應了。

我說每個用戶都可能卡這么0.0x秒，人多了咱這模塊吞吐量就沒法看了。這個咱不能接。真要接也行，得改成多線程架構，得多安排時間。

經理說沒事，直接加就行。做出事了他們負責就是(言外之意，一旦接了這個，將來我們自己的鍋也有辦法拉他們一起來背)。

既然都這么說了，我就動手做。

做完，內部測試沒有任何問題;但一上線，整個系統死了。

原因是，那個庫負荷特別大，一條數據庫更新語句能卡幾秒甚至幾十秒。將來人多了還會更卡。

經理說，算了，你改多線程吧。

我思考了三天，決定不動我們這邊的架構;而是設計個thread_call接口。任何傳給thread_call的函數都會在另外的線程里執行——為了避免讀寫到調用函數的局部變量、然后在線程執行時調用函數已退出，thread_call內部會自動申請內存，把轉交給工作函數的字符串等通過指針引用的參數統統復制過去;當線程執行結束，函數返回值也會保存在某地等待查詢(超時或查詢后自動刪除)，同時釋放用到的資源。

為了實現這個，需要一個全局單例類負責管理線程、及時清理用到的資源;同時最好有一個線程池和一個內存池，免得頻繁申請/釋放。不然長時間運行下去，把內存弄的千瘡百孔，程序就更容易出問題了。

內存池我已經寫過一個泛型版本，直接拿來用就行。剩下的線程池、資源自動申請/釋放(基于RAII和泛型，不支持原始指針因為無法確認空間大小、也無法確保復制成功，玩過泛型的都懂)，加起來一百來行代碼解決。最終代碼量300多點，其中一大半是注釋。

這個東西輕松的一次編譯通過;然后挺過了各種測試，沒發現任何問題。

這東西差不多相當于給C做了個簡易協程框架(當時協程概念還沒流行起來，不然我就把yield也實現進去了)，今后遇到任何類似的“需要并行工作、但又不涉及數據競爭”的需求，直接寫個處理函數然后丟給thread_call執行就好。

你看，如果程序都照這樣寫，是不是就會越寫越快?

因為你昨天寫的東西，今天可以拿來就用。寫的越多，積累越多，實現新功能時需要重新實現的東西就越少，效率自然越高。

04

但是這個東西讓項目經理作了難。

這是因為，如果算KPI的話，等于我花一周寫了300行代碼;然后又測了一周……兩周300行代碼的產出，這實在太少了。

反觀別人，一個用戶注冊，人家一個字段一個字段一個字節一個字節的用代碼檢查、復制，輕輕松松搞出來500行。很水的幾個功能輕松灌水上萬行代碼，然后部門KPI也有了，個人重要性也體現了——而且修不完的bug：你看，離了我們這個部門，公司真不能過啊!

可我傻乎乎的300行代碼搞出這么復雜個東西，竟然還測不出bug……項目經理是知道這里面功能多，但上面覺得你忽悠他。300行代碼你還能吹出花來不成?

而且，既然沒有bug，以后人家還需要你這個部門嗎?問題都解決了，我們這些人……還有繼續雇傭的必要嗎?

總之，他希望以后再寫程序，盡量寫長一些……而且，為什么要復用呢?其實每一個類似的需求，都是可以給他整個幾萬行代碼出來的嘛。

05

沒錯。人家的預期是：這是個挺復雜挺難的任務，你應該加班加點忙上幾個星期，提交幾千上萬行代碼，到時部門KPI有了個人業績也好看——將來每個類似任務都應照此辦理。

而我呢，輕輕松松300行代碼，杜絕了類似任務的出現——什么都不用管，加一行thread_call，全都妥妥貼貼了。

一個任務對應一行，這KPI還能看嗎?

你看，面向目標的不同，面向KPI編碼就必然使得實現臃腫、問題頻發、每天996過勞死……但做起來其實輕松愉快，因為你完全可以磨上仨月洋工，然后吹噓“多線程有多難”;然后還能讓高層不斷找你、解決諸如野指針、數據臟讀臟寫、死鎖、內存碎片導致長時間運行后大塊內存分配失敗等等等等疑難問題——既讓你顯得重要，又能輕輕松松“騙”來大量的KPI，最后還不需要去學鬼畫符一樣、難的不要不要的泛型技術……

而面向問題編碼呢，借助泛型，自動識別、復制函數參數(它們可能來自調用者的棧，隨時可能失效)，再加上用池來加速資源回收/分配效率、提前杜絕內存碎片問題——這完全是個簡單輕松解決的小模塊。而且只需解決一次，我們自己的“類協程庫”都出來了，以后寫程序會越來越快、越來越好：你甭管我怎么做完的、耗了多少時間，功能點我給你實現了、上線后bug free，是不是對雙方都有利?

06

但是，后者在這個公司行不通。

代碼量少沒KPI你氣不氣?

bug寫的少沒人找你顯得你不重要，倒霉不倒霉?

將來項目失敗抓人背鍋時，別人說我天天加班996007態度端正;而你呢，955一分鐘班不加，這態度是不是很能說明問題?

從上到下都不懂你能怎么的?

別說這家公司的管理者了，他們的技術人員自己都不懂。我兩個關系比較好的同事，還真以為我們是公司里干活最少、最不重要的幾個呢。

因為別人忙忙碌碌總有干不完的活、修不完的bug，高層中層領導天天圍著轉，求爺爺告奶奶但任務就是做不完，重要的不得了。而我們幾個公司公認的技術專家呢，每天到時間就走;座位上冷冷清清，從無領導過問;經常上班時間閑極無聊于是借“學新技術”的名義逛論壇……

時間久了，他們自己都心虛：為啥別人總是有干不完的活、見不完的領導?為什么我們經常整周整周的沒有任務、閑坐著發呆?人家是不是比我們干的多、任務難啊?不對啊，每次分配任務，分給我們的，都是別人接不了、不敢接的啊?

07

直到有一天，午飯后散步聊天打屁談到這事，我才覺得不對，提議回去看看工作日志/提交記錄之類東西。

那天我們大概照例聊到了下午三點吧——沒錯，因為事少，因為要都要不來工作，一個月至多也就忙一周，955都大塊大塊的空閑時間。別說加班了，平常上班我們都經常偷空出去散步。

悠哉游哉回到公司之后，我們就去翻看所有同事的提交記錄和bug報告數據。這才驚訝的發現，我們比其他同事完成的功能點數量高出5~10倍、難度也普遍更高，bug率卻近乎為0——別人一個功能點能有密密麻麻幾十個bug，而且上線幾年bug都抓不完;而在我們看來，這些都是壓根就不應該發生的低級錯誤，而且我們提交的代碼的確不包含這類錯誤。

所以，別人一年只做三四個功能點，每個功能點都要出十幾、幾十個bug;而我們呢，一年起碼幾十個功能點，加起來不過3~5個bug(我更是一年只有1個bug，而且bug原因還是需求沒寫清：某個字段讓返回字符串，我按照C慣例后面加了個‘\0’;對方用的java，不能識別這個\0)。

08

問題是，“我們接的任務最多最難”，這事我們項目經理知道，中高層領導不知道。

中高層領導知道什么呢?他們只知道，這個任務總是在別人那里卡住;他們只知道，系統出了問題，該找的人肯定不是我們幾個(從不出bug自然不需要找)——所以你猜，在他們心里，誰更重要?

09

于是我決定辭職。

這是我第一次進這種公司，也是最后一次。

因為這種公司完全是“逆淘汰”。水平越差越吊兒郎當越吃香，水平越高越兢兢業業越被邊緣化。