[[332751]]

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

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

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

01

是的，他們效率更高。

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

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

因為中高層傻。

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

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

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

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

02

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

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

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

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

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

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

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

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

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

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

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

03

我曾經(jīng)接過一個任務(wù)。

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

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

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

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

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

做完，內(nèi)部測試沒有任何問題;但一上線，整個系統(tǒng)死了。

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

經(jīng)理說，算了，你改多線程吧。

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

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

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

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

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

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

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

04

但是這個東西讓項目經(jīng)理作了難。

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

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

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

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

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

05

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

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

一個任務(wù)對應(yīng)一行，這KPI還能看嗎?

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

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

06

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

代碼量少沒KPI你氣不氣?

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

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

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

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

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

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

07

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

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

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

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

08

問題是，“我們接的任務(wù)最多最難”，這事我們項目經(jīng)理知道，中高層領(lǐng)導(dǎo)不知道。

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

09

于是我決定辭職。

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

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