閱讀本文大概須要 4 分鐘。html
悟空之友的故事mysql
今年年初，到一家互聯網公司實習，該公司是國內行業龍頭。程序員
不過技術和管理方面，卻弱爆了。算法
那裏的程序員，天天都在看郵件，查問題工單。spring
這些問題，多半是他們設計不當，形成的。sql
代碼寫的一團糟，全是複製粘貼，連做者都沒改，你們廣泛不寫註釋，也不格式化，代碼歪歪扭扭。編程
一個項目裏，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 ，圖文效果爲原創，若有侵權，請聯繫刪除。
往期精彩回顧
原文出處：https://www.cnblogs.com/gdjk/p/10712891.html