閱讀本文大概需要 4 分鍾。
悟空之友的故事
今年年初，到一家互聯網公司實習，該公司是國內行業龍頭。
不過技術和管理方面，卻弱爆了。
那里的程序員，每天都在看郵件，查問題工單。
這些問題，多半是他們設計不當，造成的。
代碼寫的一團糟，全是復制粘貼，連作者都沒改，大家普遍不寫注釋，也不格式化，代碼歪歪扭扭。
一個項目里，httpclient竟然出現了四種。
一種是該公司研發部寫的，
一種是老版本的開源項目，
一種是新版本的開源項目，
還有一種是開發人員造的輪子。
打接口請求響應日志，竟然不知道用攔截器。打錯誤日志竟然不打上下文信息，每個人一種日志風格，千奇百怪。許多重要的中間流程，居然不打日志。
idea、eclipse、myeclipse的配置文件竟然全部傳到項目里去了。
該公司混了兩年的程序員，跟快遞公司做查詢接口，竟然不知道加密運單號。
所有服務間通訊，都沒有設requestId，導致跟蹤會話很困難。
一個沒什么qps的邊緣接口，居然做消費者生產者+阻塞隊列的異步模式。顯得你技術少是不是。不知道異步會增加維護成本，提高測試難度嗎？而且，任務隊里沒有考慮持久化，趕上發布，丟了好多任務。
讀取一個小小的xml和exc配置文件，居然用流式解析，沒見過這么二逼的，真是醉了。
做優化全靠拍腦門拍大腿，難道不會用excel分析日志，用jprofile掃項目？
一個100以內的常數集合遍歷，他也要寫個優化算法進去，算法跟業務還攪在一起，一團亂麻。
每個人都在嚷嚷性能、算法、分布式計算……
幾乎沒有文檔，全靠從代碼反推邏輯。
有枚舉他不用，非要在每個頁面上，把枚舉值挨個兒寫死，知道后面改代碼多么費勁嗎？
欺騙性的變量名，里面存儲的是AES加密的，變量名后綴卻寫成了DES；里面存的是小寫字母，卻寫成upperStr。
一個方法十幾個參數，有三分之一是極其簡略的縮寫，注釋肯定也沒有的。
一個類寫到三四千行是常事。
開發自測，居然要把代碼全丟到公共機器上，而且都是走svn，他們把svn當ftp用。
svn里面大量的無意義提交，一多半的提交連都編譯不過去。
我看到有個應屆生，改了兩句話，馬上提交，說是怕代碼丟失。
一個運行了兩年的項目，spring的包掃描明顯配錯了，有些bean根本掃不進來，居然沒有人發現。
一半的bean在spring管理下，另一半的bean他們自己寫單例模式來實例化。
他們用mysql來做審計系統，出報表，有個報表要跑8分鍾。
原來是有人用字符串來存多值（逗號分隔），sql里寫了like，導致沒有利用到索引。
為什么不用pg，pg在sql編程方面，功能更豐富，更適合做統計，它本身就支持數組。
程序員們都是得過且過的態度，怎么把代碼灌進去，跑的通測試，就算交差了。
為什么大型互聯網公司，技術和管理這么差勁，是怎么形成的？（這家公司是賣機票的，沒有明確說出公司名字，是怕給自己惹麻煩）
甲：這個A開源庫舊版本有崩潰問題啊。
乙：換新版本的A。
甲：換了新版本A，用舊的 GCC 編譯不過啊。
乙：換新版本GCC。
甲：換了新版本GCC，B開源庫不兼容啊。
乙：換新版本的B。
甲：換了新版本的B，導致性能下降啊。
乙：開多線程。
甲：開了多線程導致延遲抖動不同步了。
乙：換新的延遲修正算法。
甲：換了新延遲修正算法偶爾會崩潰啊。
乙：要不。。。我們還是去看看那個A開源庫的舊版本崩潰能不能修好吧。
如今上點規模的IT公司，其軟件項目的規模和復雜度都遠遠超過工程師的能力上限了，都只能小心翼翼地修補。
有時局部的大改動會引發連鎖反應，大改動的風險和成本很難控制，沒有巨大的收益誰也不敢隨便改，你能看到的問題老員工看得更清楚，甚至也清楚怎么解決，但是不動手的原因就是不知道出了事誰來背黑鍋，技術上的事情誰敢說100%不出事的。
那是不是大公司的技術項目就沒救了呢？
也不一定，有些事要等個機會的，常見的機會：
1. 技術基礎平台大革命，比如移動互聯網的興起，從PC遷移到了手機端，很多舊的技術代碼就可以拋棄了，手機上從零開始。
2. 競爭對手小宇宙爆發，對手搞出一項技術取得了競爭優勢，被迫追趕，這時候死馬當活馬治，改出任何問題也都能忍了。
3. 人事大動盪，管理層和基層都大換血，舊代碼已經沒人有能力維護下去了，不得不重來。
碼農西游特別申明：本文文字內容轉自 www.raychase.net/3529 ，圖文效果為原創，如有侵權，請聯系刪除。
往期精彩回顧
