[[159168]]

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

“看題目以為是題主傻逼，看了正文發現真的是公司傻逼。”

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

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

比如這樣的話：

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

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

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

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

今年年初，到一家互聯網公司實習，該公司是國內行業龍頭。

不過技術和管理方面，卻弱爆了。

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

這些問題，多半是他們設計不當，造成的。

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

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

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

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

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

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

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

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

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

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

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

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

>> 這樣的信息是否要加密通常取決于調用兩邊的協議是怎么規定的，但是凡是涉及到隱私等等重要信息，都需要加密以減少信息泄露的風險。

所有服務間通訊，都沒有設requestId，導致跟蹤會話很困難。

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

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

顯得你技術少是不是。

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

而且，任務隊里沒有考慮持久化，趕上發布，丟了好多任務。

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

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

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

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

一個100以內的常數集合遍歷，他也要寫個優化算法進去，算法跟業務還攪在一起，一團亂麻。

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

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

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

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

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

>> 欠缺基本的程序員素質。

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

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

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

>> 看到這里我已經產生無力吐槽的感覺了。

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

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

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

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

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

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

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

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

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

為什么不用pg，pg在sql編程方面，功能更豐富，更適合做統計，它本身就支持數組。

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

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

為什么大型互聯網公司，技術和管理這么差勁，是怎么形成的？