[[159168]]

知乎上看到一個熱帖，我覺得很有意思，叫做“為什么有些大公司技術(shù)弱爆了？”。我剛看到標(biāo)題的時候，先入為主和刻板偏見了一下，正如同第一個回答一樣，我皺了皺眉頭，產(chǎn)生了對題主的鄙視之情；但是很快，讀完帖子以后，我卻立場明確地站到題主一邊了。正如同里面有位回答：

“看題目以為是題主傻逼，看了正文發(fā)現(xiàn)真的是公司傻逼。”

上面這種情況其實發(fā)生的概率挺低的，但是我覺得這回是真的發(fā)生了。

但是令我感到遺憾的是，各式各樣的回答里面，大部分居然都跳出來“教育”題主，表態(tài)這個世界就不是完美的，表態(tài)要妥協(xié)要接受這樣的事實，要無奈地咽下這個現(xiàn)實的苦果。這個大面積出現(xiàn)的觀點，太不正常了吧？

比如這樣的話：

“寫好代碼是程序員的節(jié)操。抱歉，節(jié)操多少錢一斤，北京三環(huán)商品房多少錢一平？”

有的問題實在不是能夠三言兩語回答的，尤其是當(dāng)面對整個行業(yè)的現(xiàn)實的時候，但是，可以很明確的是，當(dāng)一個項目代碼寫爛掉的時候，這個項目也活不久了。

好吧，還是就事論事，下面就貼過來，然后逐一分析其中的內(nèi)容。說說為什么大致上題主沒問題，有問題的是這家公司，這個項目組。

=================================

今年年初，到一家互聯(lián)網(wǎng)公司實習(xí)，該公司是國內(nèi)行業(yè)龍頭。

不過技術(shù)和管理方面，卻弱爆了。

那里的程序員，每天都在看郵件，查問題工單。

這些問題，多半是他們設(shè)計不當(dāng)，造成的。

>>這就是所謂的operation的工作，大多情況下很無趣。這通常也意味著系統(tǒng)復(fù)雜，負(fù)載高，問題不容易輕易定位和解決，往往是歷史遺留下來的大型系統(tǒng)。這并不奇怪，就像外人見到風(fēng)光的AWS一樣，之后內(nèi)部的工程師才知道其中有多少維護性的工作，壓力有多巨大。我記得不久前，看過一個principal talk，講oncall的折磨使他成長，我想說法不假，只是很遺憾我還到不了這個層次。題主能看到問題多半出自設(shè)計不當(dāng)，不錯。而問題居然多半是因為設(shè)計不當(dāng)，這個工程的初始架構(gòu)人員 ，以及后來架構(gòu)看護的骨干工程師，是要挨批評的。對于一個“國內(nèi)行業(yè)龍頭”，這樣的事情是不該發(fā)生的。

代碼寫的一團糟，全是復(fù)制粘貼，連作者都沒改，大家普遍不寫注釋，也不格式化，代碼歪歪扭扭。

>> 這又是一件不該發(fā)生的事情。對于代碼質(zhì)量的追求各有說法，但是“復(fù)制粘貼”、“作者都沒改”、“不寫注釋”、“不格式化”等等這樣的字眼，我不相信一般的“龍頭”公司能夠接受。這些東西就像飯要一口一口吃一樣，縱然有再大的野心，這些最最基本的細(xì)節(jié)，始終是不能忽略的。我覺得公司在招人的時候，既然是雙向選擇，就可以互亮代碼，這樣的代碼擺出來看到以后，大家就不用浪費時間了。

一個項目里，httpclient竟然出現(xiàn)了四種。一種是該公司研發(fā)部寫的、一種是老版本的開源項目、一種是新版本的開源項目，還有一種是開發(fā)人員造的輪子。

>> 最理想的情況當(dāng)然是統(tǒng)一成一種。遇到這樣多種實現(xiàn)，并且有自造輪子的情況，很多都是源于“歷史原因”。當(dāng)然，都能看到代碼簡單地“復(fù)制粘貼”了，不看以往代碼實現(xiàn)，按照自己的理解來寫也就并不奇怪了。當(dāng)然，我可以接受因為某某特殊原因而導(dǎo)致一個httpclient有多于一種的實現(xiàn)方式（我在這里還寫過造輪子的好處），但是居然有四種之多，我覺得兇多吉少了。

打接口請求響應(yīng)日志，竟然不知道用攔截器。

打錯誤日志竟然不打上下文信息，每個人一種日志風(fēng)格，千奇百怪。

許多重要的中間流程，居然不打日志。

>> 攔截器是個好東西，簡化代碼，避免啰嗦的日志影響業(yè)務(wù)邏輯的閱讀。當(dāng)然也有不好的地方，比如不直觀、不好調(diào)試，以及有時候可能發(fā)生的性能問題等等。因此這個也不強求，根據(jù)項目實際情況而定。日志風(fēng)格千奇百怪的問題，多是由于缺乏項目內(nèi)部的管理造成的，各就各業(yè)，缺少溝通。開發(fā)人員不怎么樣不說，這個項目經(jīng)理更是弱爆了。重要流程不打日志，這一條只能幫助證明這群開發(fā)人員的工程意識還欠缺。

idea、eclipse、myeclipse的配置文件竟然全部傳到項目里去了。

>> IDE用的不一樣沒事兒，但是這些IDE的配置文件也傳上去了？這樣的低級問題都出現(xiàn)……難道代碼不用review么？

該公司混了兩年的程序員，跟快遞公司做查詢接口，竟然不知道加密運單號。

>> 這樣的信息是否要加密通常取決于調(diào)用兩邊的協(xié)議是怎么規(guī)定的，但是凡是涉及到隱私等等重要信息，都需要加密以減少信息泄露的風(fēng)險。

所有服務(wù)間通訊，都沒有設(shè)requestId，導(dǎo)致跟蹤會話很困難。

>> 如果只是牽涉到服務(wù)之間的通訊，而通訊又只是簡單的查詢的話，沒有requestId我覺得是可以接受的。至于會話的跟蹤，如果這里指的是整個系統(tǒng)在一個request到達和處理的過程中，能夠跟蹤全部的或者重要的行為，比如調(diào)用了哪些接口，得到了哪些結(jié)果，做了哪些操作等等，這個功能確實是很有必要的，但是這個跟蹤是可以在服務(wù)間通訊沒有requestId做到的。比如在主系統(tǒng)中使用一個線程變量，在每次打印這些信息的時候把線程變量放置在前面，后續(xù)的日志分析工具就可以捕捉到這次會話交互的所有日志。

一個沒什么qps的邊緣接口，居然做消費者生產(chǎn)者+阻塞隊列的異步模式。

顯得你技術(shù)少是不是。

不知道異步會增加維護成本，提高測試難度嗎？

而且，任務(wù)隊里沒有考慮持久化，趕上發(fā)布，丟了好多任務(wù)。

>> 沒什么qps的邊緣接口，做成這樣的異步模式，看起來是有點殺雞用牛刀了。但是這個事情要結(jié)合背景去分析，比如有可能是為了未來的擴展需要，有的接口可以預(yù)見到請求量會大幅增加。當(dāng)然，結(jié)合整個上下文來看，我更傾向于是這個項目組疏于管理，然后來了一個自恃牛逼的“大拿”，整了一套高大上唬住大伙兒；或者是一個很想在項目中嘗試新東西的小哥，就拿這東西練手了。至于任務(wù)隊里沒有持久化這個一條，依然要看具體的問題，不過通常情況下，如果要設(shè)計一個通用的任務(wù)隊列，持久化是一個必選項。當(dāng)然話也不能說死，你是要搞完全不在乎任務(wù)丟失的，或者任務(wù)調(diào)度者可以不斷地重試那些掛掉的任務(wù)，于是你不在乎他們丟失的問題——不過想想好像這樣的case挺少的。

讀取一個小小的xml和exc配置文件，居然用流式解析，沒見過這么二逼的，真是醉了。

>> 這和上面那個殺雞用牛刀是同一個問題，已經(jīng)闡述過了。

做優(yōu)化全靠拍腦門拍大腿，難道不會用excel分析日志，用jprofile掃項目？

一個100以內(nèi)的常數(shù)集合遍歷，他也要寫個優(yōu)化算法進去，算法跟業(yè)務(wù)還攪在一起，一團亂麻。

每個人都在嚷嚷性能、算法、分布式計算……

>> 看起來這里指的是性能方面的優(yōu)化，那么做優(yōu)化至少包括兩部分，一部分是在設(shè)計階段就要分析需求層面的數(shù)據(jù)推出要“優(yōu)化”到什么程度，另一部分才是題主說的根據(jù)日志和已有項目運行的數(shù)據(jù)“反推 ”（幾年前寫過一點這方面的東西）。當(dāng)然，無論哪個，都比拍腦門和拍大腿靠譜得多。至于100以內(nèi)常數(shù)集合遍歷，也要寫優(yōu)化算法，這有時未必是件壞事，比如大家都在遵循最佳實踐，不過結(jié)合上下文看（包括“算法和業(yè)務(wù)攪在一起”），我更傾向于是屬于前面已經(jīng)闡述過的問題。就這種狀況下，每個人都還嚷嚷“性能、算法、分布式計算”就顯得有點沒抓到主要矛盾了，主要矛盾應(yīng)該是把這些代碼最基本的問題給解決了。我記得小時候練習(xí)書法的時候，老師批評過我：先不要嘗試那些技巧，先把最基本的橫平豎直給練好了。

幾乎沒有文檔，全靠從代碼反推邏輯。

>> 代碼和文檔經(jīng)常是對立面，這樣的狀況并不稀奇。我覺得比較可行的做法是，有概要的文檔，但是詳細(xì)文檔往往不現(xiàn)實，即使寫了也難免過時。公司內(nèi)部的文檔太多太多是一坨漿糊。

有枚舉他不用，非要在每個頁面上，把枚舉值挨個兒寫死，知道后面改代碼多么費勁嗎？

>> 欠缺基本的程序員素質(zhì)。

欺騙性的變量名，里面存儲的是AES加密的，變量名后綴卻寫成了DES；里面存的是小寫字母，卻寫成upperStr。

一個方法十幾個參數(shù)，有三分之一是極其簡略的縮寫，注釋肯定也沒有的。

一個類寫到三四千行是常事。

>> 看到這里我已經(jīng)產(chǎn)生無力吐槽的感覺了。

開發(fā)自測，居然要把代碼全丟到公共機器上，而且都是走svn，他們把svn當(dāng)ftp用。

svn里面大量的無意義提交，一多半的提交連都編譯不過去。

我看到有個應(yīng)屆生，改了兩句話，馬上提交，說是怕代碼丟失。

>> 自測走svn其實不稀奇。就像自己開發(fā)一個新功能在git下可以cut一個新的branch，然后開發(fā)了，提交了，部署到各種機器上去。不過當(dāng)ftp用顯然是不對的。“一半多編譯不過去的提交”，這個項目沒有項目管理嗎？開發(fā)機上不單元測試嗎？至于“改了兩句話，馬上提交”，沒看出有什么不妥，只要提交前的測試、review等等通過。

一個運行了兩年的項目，spring的包掃描明顯配錯了，有些bean根本掃不進來，居然沒有人發(fā)現(xiàn)。

一半的bean在spring管理下，另一半的bean他們自己寫單例模式來實例化。

>> 第一條依然是項目組疏于管理的佐證。即便是主力程序員，也缺少對項目整體的責(zé)任感，或者是代碼爛得讓人難以提起興致。第二條則是一個典型的不好的實踐。有時候可能會需要這樣的妥協(xié)，但是居然有一半的bean脫離Spring的管理，那最初引入Spring干嘛？

他們用mysql來做審計系統(tǒng)，出報表，有個報表要跑8分鐘。

原來是有人用字符串來存多值（逗號分隔），sql里寫了like，導(dǎo)致沒有利用到索引。

為什么不用pg，pg在sql編程方面，功能更豐富，更適合做統(tǒng)計，它本身就支持?jǐn)?shù)組。

>> 報表跑8分鐘很正常。Sql用字符串存多值這個，沒有利用索引，還是要分析具體問題，原則上我不覺得有什么問題。要想完美解決這個問題，還是在mysql里面，就得把多值拆解成多行，放到一張新表里面去。另外，也有一些NoSQL系統(tǒng)天然支持value多值，比如DynamoDB，不過這是題外話。至于為什么不用pg，這涉及到最初的技術(shù)選型，后人看的時候只是說說“如果用xxx就yyy了”當(dāng)然容易，但是不清楚最初是否有技術(shù)層面的考量。當(dāng)然，這個項目那么爛，也許是一開始圖方便搞了mysql的prototype就上了。無論如何，有質(zhì)疑的想法總是值得鼓勵的。

程序員們都是得過且過的態(tài)度，怎么把代碼灌進去，跑的通測試，就算交差了。

為什么大型互聯(lián)網(wǎng)公司，技術(shù)和管理這么差勁，是怎么形成的？