為什么感覺有些大公司的技術偏弱？

其實很多時候，導致問題出現的原因因素會有很多，但有的時候，很多問題的發現，也是因為對現有情況和事情的不全面了解所導致的。

以下是一個牛企的過來人以個人經歷分享的現實情況，希望可以有所幫助！

新手經常會有這樣的想法一「這代碼怎 么這么爛?寫的人干什么吃的?怎么能這樣?為什么不按照書上說的做?」，這很正常，大家都年輕過，經歷過這種階段，我懂你心里的想法,所以也愿意詳細地向你解釋，這- -切發生的原因是什么。

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

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

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

你真的覺得「國內行業老大的互聯網公司」會是技術和管理弱爆了的樣子嗎?

你以為團隊應該像永動機，但現實永遠有各種摩擦、輻射、損耗。

內燃機的能量轉化率，通常只有30% - 50%，但是它卻是驅動全世界運轉的核心引擎，順豐京東的快遞小車、聯通全國的高鐵動車綠皮、瞬時直達的飛機......

機器尚不能100%效率運轉，何況是人呢?

你說我們的程序員每天都在查看郵件、問題工單，你說這些問題多半是我們設計不當造成的，請問你有試過統計數據嗎?你大概只是「感覺j如此吧?

事實上，經過十幾年的發展，我們內部的效率改進團隊g已經非常高效成熟，每月、每周、甚至每天都會有新的改進，現在的業務處理方式，不說全世界，我可以自豪地說在全國我們是領先的，甚至是遙遙領先，不然憑啥坐到了全國龍頭老大的位置呢?

所以啊，你只看到了程序員花在業務上的時間，沒看到我們內部的「效率改進團隊」為程序員們省掉的時間，我覺得我有必要站出來為默默付出的效率改進團隊J說幾句。

當然，樓主作為實習生，不知道這些事情進而產生了這些疑問，也暴露了我們的不足。我已經在團隊建設委員會j里提出了這個問題，大家一致通過了決議，以后我們會對新員工一包括實習生加強企業文化、歷史培訓，確保我們的新伙伴們不僅知道要去哪兒，也要清楚我們從哪里來，長路漫漫，我們一同前行。

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

當初公司起步的時候，整個項目都是幾個初創程序員加班加點熬出來的，我知道你看過《代碼大全》、《程序員修煉之道》、 《Unix編程藝術》，你對上面的準則信手拈來，你可否翻開床頭柜.上的這幾本書，看看它們的出版時間呢?

是的，公司起步的時候，這幾本書根本還沒有出版，彼時中國互聯網方興未艾，大家都是摸著石頭過河。現在你遇到問題，你可以問朋友、問導師、用谷歌、用棧溢出、用知乎，我們寫程序那個年代，看的是譚浩強、嚴蔚敏，用的是52k撥號上網，語言只有C，編輯器是沒有語法高亮和實時編譯的，編譯器是沒有智能準確的報錯的，沒有現在這么多知識、也沒有這么多規范和好資源、好工具。不過我們還是把項目做出來了，把公司一步步推到了現在的位置。

不過這個問題是客觀存在的問題，誰也不否認，但是你知道為什么你被分配到了一-個代碼看上去一團糟也不夠規范g的項目嗎?我們需要新鮮血液來重構一些老代碼，所以你會被分配到艱苦的崗位.上。我們希望你是勇于戰斗的戰士，我們更希望你能成長為經驗豐富的老兵，而把你放到這種崗位，是對你來說成長最快的方式。

你認為「一個項目里，httpclient竟 然出現了四種。-種是該公司研發部寫的，

一種 是老版本的開源項目，-種是新版本的開源項目，還有一-種是開發人員造的輪子。」

你不知道的是，我們最初用了開源軟件(也就是你所說的「老版本」)，它構成了我們早期項目的基石，隨著業務復雜性增加，我們改進并最終切換到新版本。

這個軟件跑老業務非常成熟，但是在一- 些新業務上有不可調和的矛盾，所以在痛苦的適配后,研發部的同事們自告奮勇用20%的時間寫了新業務的組件一是的你沒看 錯我們也有20%時間，我們鼓勵工程師的創新。

至于你說的開發人員造的輪子一這 說起來可真有趣，它其實是前年來的一個清華大學實習生寫的。

當時他來了之后，針對他接手業務的需求，向我抱怨說現有的3種都不好，要寫-個新的來C統- -天下g，這話是他的原話，我記得非常清楚，因為以我多年經驗來看這樣的做法是不可取的，但是本著鍛煉年輕人的心態(加上他的確是不可多得的天才)，我同意了他的請求，于是我用自己的業余時間接管了他的大部分工作，全力支持他寫一個新的組件，幫他擋住了所有上面的壓力，后來的故事就是你看到的這樣。

是的，他后來越深入、就越來越感到業務的復雜，不斷推翻重構、拆東墻補西墻，但始終發現和自己想的根本完全不一樣，受不了了就走了，留下來這個。

我們明年的規劃中，就包括剔除這個組件的codebase,因為它實在是太糟糕了。你又說「打接口請求響應日志，竟然不知道用攔截器。

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

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

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

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

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

攔截器并不如你所想的那班美好，也許你在自己的電腦上寫過一些玩具代碼，覺得這樣很方便、酷炫，但是真正到了戰場，你會發現沒什么才是必須的、好的，只有適合的才是對的。

至于配置文件，這么說吧，IDE 的配置文件傳到代碼倉庫是我定下的規矩，怎么會有 人定這樣的規矩?」，是的你可能從軟件工程的教科書上或者某些知名博客j.上 讀到了不能這樣做，但實際上這樣做在很多情況下是必須的。

原因何在?

這樣可以確保代碼克隆即可用，而不是讓每個人都去設置一大堆無聊的東西，這樣不僅節省時間，也確保了每個人的環境一 致性，你想想這幾年火熱的docker， 應該明白了這樣做的正確性和必要性了吧?

你可能會說即便如此、插件也不用上傳到服務器保存，我告訴你這樣是不行的，你要考慮到我們這個項目前后十余年，你覺得幾個插件能堅挺十余年?很可能我們早期用的軟件，現在你已經完全不可能找到了，所以保存- -份備份是非常有必要的，決不能錯誤地認為是冗余。

教科書只會教你基本通用的原則，樹立你基本正確的觀念，但是如果只是死守教條，如何能擁抱日益復雜的變化呢?

你看的教科書，且不說時間上已經是二十多年前的了，在適用性上，也不說就是真理，IT 行業發展日新月異，幾個月就是滄海桑田，為了適應這樣的變化，認真地思考、總結、判斷才是最重要的。

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

顯得你技術少是不是。

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

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

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

你大概不知道，當初跑在你口中的「-一個沒什么qps的邊緣接口」.上面的業務帶來 了公司曾經90%的收入，所以我們用了復雜的設計以應對當時的需求，當然現在業務轉變，老系統不再需要處理那么多業務了，但是更沒有理由為一個"works perfectly wellg并且不再重要的業務重構代碼吧?

所以，不是我們秀技術，而是業務需求業務變更使然，年輕人還需要多學習一個。

你抱怨「做優化全靠拍腦[ ]拍大腿，難道不會用excel分析 日志，用jprofile掃項目?

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

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

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

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

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

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

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

我再強調一次一我們是全 中國同類公司中技術能力第一的，你所說的問題，當然是不存在的。

我們有專門的Hadoop集群來分析日志，當然也就用不著Excel 了。

對于我們這種體量的公司來說，不存在什么「常 數集合j，代碼必須用合適的數據結構一這是常識吧?

特殊的算法和業務摻雜以增加內聚性，這是我們多年的經驗，的確，它和教科書上說的不一樣，但是我前面說了，死守教條是不行的一想必你一定知道OSI 7層網絡模型吧?

公司的技術氛圍濃厚，是和公司的基因分不開的，我們公司最重要的原則就是一F 擁抱變化J，從十幾年前的機房托管單機到現在的龐大自建集群，技術躍遷了何止千萬里，所以每個人都在學習新知識、每個人都沉浸在新知識的喜悅中。

你的問題，大多都是因為沒有考慮到公司的龐大體量和十幾年的技術躍遷才有的疑問，這點不再贅述，自行體會吧。

你想的是

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

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

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

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

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

其實那不是SVN,那是我們公司自主研發的適應我們內部需求的源代碼管理系統和文件管理系統，你可以往里面放任何東西。

你所說的「無意義提交、一多半的提交連都編譯不過去」其實只是表象，這套系統代號

TITAN，它自帶CIDD (持續繼承、交付、部署)，所以這些無法編譯的提交都是不會有機會走到下一步流程的的。

如果你工作了一年，你就會發現這個需求是很重要的，改動、尤其是大型改動，中間會有很多非可用但有需要存檔的步驟，現有的源代碼管理系統都不能很好地支持這些需求，因此你也被教育了一套適應落后工具的思想。人啊，最重要的能力是改進工具，所以用TITAN的時候要擁抱全新思維，不要被落后思維捆綁。

如果你工作了幾年，你可能還會問為什么我們沒用Jenkins、Travis 等工具，其實呀，就在TITAN之中呀，它凝結了公司最優秀的人才的十幾年寶貴經驗和心血。

By the way,我們最近正計劃開源它，為中國開源社區做貢獻，也希望提高業界的綜合素質。歡迎你提交PR哦！

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

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

為什么不用pg，pg在sq|編程方面， 功能更豐富，更適合做統計，它本身就支持數組。程序員們都是得過且過的態度，怎么把代碼灌進去，跑的通測試，就算交差了。

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

為什么不用pg?如果你抱著這種想法，那用了pg也要被噴的，到時候就就會說-一「為什么不用sqlite, 輕量簡單，搞這么復雜真的有必要嗎?」，真的有必要。。

這只是一個很簡單的系統，做的事情也很簡單，當初做這個系統的同事更熟悉MySQL，當然MySQL是不二之選了，對于簡單的東西，追求的是開發速度、使用便利性。

你覺得一個月跑一次的審計代碼，8分鐘有什么問題嗎?就算是一-周跑一次，當然也是沒問題的。

程序員的單位時間是如此寶貴,為了優化一段- -個月跑一次的8分鐘代碼，值得花費數天的時間來做這件事嗎?

重復一遍，有這樣的問題，大多都是因為「沒有考慮到公司的龐大體量和十幾年的技術躍遷才有的疑問j，這點不再贅述，還請自行體會。

當然，年輕人樂于思考，這是好事，是希望，新鮮血液替換老舊部件系統才能健康發展成長，人如此、公司如此、國家也是如此。

希望你勤于思考，努力學習，有問題的話，我們公司是鼓勵同事們向CEO、CTO寫信的，不然也不會有CEO、CTO信箱了你說對嗎?

當然，這樣的技術性問題、你寫給我就好，CEO是船長，不需要關心底層鍋爐房的細節。另外我想補充一下我的想法，希望對你有所幫助。

你看你都沒說加班問題，我們公司沒加班啊，這多好，怎么做到激烈競爭下還能不加班的?都虧了公司老領導和元老們的一手決策。

所以我想補充的不是技術問題，技術問題都不是問題，年輕人可以學習、交流，技術都會很快成長，畢竟年輕人的沖勁大、頭腦靈活。

我想說的是整體觀、大局觀、大棋戰略。

黃金的導電性最好，為什么電腦主板還要用銅?

清華大學最好，為什么有人要去普通學校?飛機最快，為什么還有人坐火車?

因為資源都是有限的，我們在現實生活中一-而不是教科書 上一必須兼顧 成本和產出的平衡。

你問我每行代碼都多人多層人工review好不好?問我支不支持?我說好，review 我怎么能不支持呢?我今天在知乎這個公眾平臺我明確說了我支持。

但是你也應該多學習一個，這個現實畢竟是現實，我們要兼顧各種考量。

以上就是該大牛企業員工的相關分享

其實，很多時候「大公司技術和管理這么差勁」，這樣的問題可能是在沒有了解清楚全面的情況下的武斷結果。

但也有很多情況下確實會存在，可仔細想想，連一般的公司以外或者基礎員工都能發現的問題，作為公司的高層管理人員或者董事會成員會不知道，會看不出來么？

不是的，其實他們可能會看的更加清楚，更加透徹，也更加想改變現狀。可真正推行的改變卻不是一件小事情，大公司之所以成為了大公司，在已經是方方面面都是千絲萬縷，牽一發而動全身，一個決策的操作不當，很有可能會引發連鎖的蝴蝶效應，所以更不太容易改變。

總結就是，生產效率才是最重要的，世間萬物最重要的是平衡。

怎樣取舍、如何妥協，這不僅是大自然的規律，也是我們前進、發展的準繩和仰仗的原則。