點擊藍色「Python空間」關注我丫mysql
加個「星標」，天天一塊兒快樂的學習程序員
有網友提問：算法
今年年初，到一家互聯網公司實習，該公司是國內行業龍頭。不過技術和管理方面，卻弱爆了。那裏的程序員，天天都在看郵件，查問題工單。這些問題，多半是他們設計不當，形成的。代碼寫的一團糟，全是複製粘貼，連做者都沒改，你們廣泛不寫註釋，也不格式化，代碼歪歪扭扭。spring
一個項目裏，httpclient居然出現了四種。一種是該公司研發部寫的，一種是老版本的開源項目，一種是新版本的開源項目，還有一種是開發人員造的輪子。sql
打接口請求響應日誌，居然不知道用攔截器。docker
打錯誤日誌居然不打上下文信息，每一個人一種日誌風格，千奇百怪。編程
許多重要的中間流程，竟然不打日誌。數組
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編程方面，功能更豐富，更適合作統計，它自己就支持數組。
程序員們都是得過且過的態度，怎麼把代碼灌進去，跑的通測試，就算交差了。
爲何大型互聯網公司，技術和管理這麼差勁，是怎麼造成的？
蕭井陌的回答：
地址：www.zhihu.com/question/32039226/answer/76059969
樓主你好，我試着給你解釋一下，但願你能滿意。
新手常常會有這樣的想法——「這代碼怎麼這麼爛？寫的人幹什麼吃的？怎麼能這樣？爲何不按照書上說的作？」，這很正常，你們都年輕過，經歷過這種階段，我懂你內心的想法，因此也願意詳細地向你解釋，這一切發生的緣由是什麼。
你說
「不過技術和管理方面，卻弱爆了。那裏的程序員，天天都在看郵件，查問題工單。這些問題，多半是他們設計不當，形成的。
你真的以爲『國內行業老大的互聯網公司』會是技術和管理弱爆了的樣子嗎？
你覺得團隊應該像永動機，但現實永遠有各類摩擦、輻射、損耗。
內燃機的能量轉化率，一般只有 30% – 50%，可是它倒是驅動全世界運轉的核心引擎，順豐京東的快遞小車、聯通全國的高鐵動車綠皮、瞬時直達的飛機……
機器尚不能 100% 效率運轉，況且是人呢？
你說咱們的程序員天天都在查看郵件、問題工單，你說這些問題多半是咱們設計不當形成的，請問你有試過統計數據嗎？你大概只是『感受』如此吧？
事實上，通過十幾年的發展，咱們內部的『效率改進團隊』已經很是高效成熟，每個月、每週、甚至天天都會有新的改進，如今的業務處理方式，不說全世界，我能夠自豪地說在全國咱們是領先的，甚至是遙遙領先，否則憑啥坐到了全國龍頭老大的位置呢？
因此啊，你只看到了程序員花在業務上的時間，沒看到咱們內部的『效率改進團隊』爲程序員們省掉的時間，我以爲我有必要站出來爲默默付出的『效率改進團隊』說幾句。
固然，樓主做爲實習生，不知道這些事情進而產生了這些疑問，也暴露了咱們的不足。我已經在『團隊建設委員會』裏提出了這個問題，你們一致經過了決議，之後咱們會對新員工——包括實習生增強企業文化、歷史培訓，確保咱們的新夥伴們不只知道要去哪兒，也要清楚咱們從哪裏來，長路漫漫，咱們一同前行。
你以爲
「代碼寫的一團糟，全是複製粘貼，連做者都沒改，你們廣泛不寫註釋，也不格式化，代碼歪歪扭扭。
當初公司起步的時候，整個項目都是幾個初創程序員加班加點熬出來的，我知道你看過《代碼大全》、《程序員修煉之道》、《Unix 編程藝術》，你對上面的準則信手拈來，你能否翻開牀頭櫃上的這幾本書，看看它們的出版時間呢？
是的，公司起步的時候，這幾本書根本尚未出版，彼時中國互聯網方興未艾，你們都是摸着石頭過河。如今你遇到問題，你能夠問朋友、問導師、用谷歌、用棧溢出、用知乎，咱們寫程序那個年代，看的是譚浩強、嚴蔚敏，用的是 52k 撥號上網，語言只有 C，編輯器是沒有語法高亮和實時編譯的，編譯器是沒有智能準確的報錯的，沒有如今這麼多知識、也沒有這麼多規範和好資源、好工具。不過咱們仍是把項目作出來了，把公司一步步推到了如今的位置。
不過這個問題是客觀存在的問題，誰也不否定，可是你知道爲何你被分配到了一個『代碼看上去一團糟也不夠規範』的項目嗎？咱們須要新鮮血液來重構一些老代碼，因此你會被分配到艱苦的崗位上。咱們但願你是敢於戰鬥的戰士，咱們更但願你能成長爲經驗豐富的老兵，而把你放到這種崗位，是對你來講成長最快的方式。
你認爲
「一個項目裏，httpclient居然出現了四種。一種是該公司研發部寫的，一種是老版本的開源項目，一種是新版本的開源項目，還有一種是開發人員造的輪子。
你不知道的是，咱們最初用了開源軟件（也就是你所說的『老版本』），它構成了咱們早期項目的基石，隨着業務複雜性增長，咱們改進並最終切換到新版本。
這個軟件跑老業務很是成熟，可是在一些新業務上有不可調和的矛盾，因此在痛苦的適配後，研發部的同事們挺身而出用 20% 的時間寫了新業務的組件——是的你沒看錯咱們也有 20% 時間，咱們鼓勵工程師的創新。
至於你說的開發人員造的輪子——這提及來可真有趣，它實際上是前年來的一個清華大學實習生寫的。
當時他來了以後，針對他接手業務的需求，向我抱怨說現有的 3 種都很差，要寫一個新的來『統一天下』，這話是他的原話，我記得很是清楚，由於以我多年經驗來看這樣的作法是不可取的，可是本着鍛鍊年輕人的心態（加上他的確是不可多得的天才），我贊成了他的請求，因而我用本身的業餘時間接管了他的大部分工做，全力支持他寫一個新的組件，幫他擋住了全部上面的壓力，後來的故事就是你看到的這樣。
是的，他後來越深刻、就愈來愈感到業務的複雜，不斷推翻重構、拆東牆補西牆，但始終發現和本身想的根本徹底不同，受不了了就走了，留下來這個。
咱們明年的規劃中，就包括剔除這個組件的 codebase，由於它實在是太糟糕了。
你又說
「打接口請求響應日誌，居然不知道用攔截器。打錯誤日誌居然不打上下文信息，每一個人一種日誌風格，千奇百怪。許多重要的中間流程，竟然不打日誌。idea、eclipse、myeclipse的配置文件居然所有傳到項目裏去了。該公司混了兩年的程序員，跟快遞公司作查詢接口，居然不知道加密運單號。全部服務間通信，都沒有設requestId，致使跟蹤會話很困難。
攔截器並不如你所想的那班美好，也許你在本身的電腦上寫過一些玩具代碼，以爲這樣很方便、酷炫，可是真正到了戰場，你會發現沒什麼纔是必須的、好的，只有適合的纔是對的。
至於配置文件，這麼說吧，IDE 的配置文件傳到代碼倉庫是我定下的規矩，『怎麼會有人定這樣的規矩？』，是的你可能從軟件工程的教科書上或者某些『知名博客』上讀到了不能這樣作，但實際上這樣作在不少狀況下是必須的。
緣由何在？
這樣能夠確保代碼克隆便可用，而不是讓每一個人都去設置一大堆無聊的東西，這樣不只節省時間，也確保了每一個人的環境一致性，你想一想這幾年火熱的 docker，應該明白了這樣作的正確性和必要性了吧？
你可能會說即使如此、插件也不用上傳到服務器保存，我告訴你這樣是不行的，你要考慮到咱們這個項目先後十餘年，你以爲幾個插件能堅挺十餘年？極可能咱們早期用的軟件，如今你已經徹底不可能找到了，因此保存一份備份是很是有必要的，決不能錯誤地認爲是冗餘。
教科書只會教你基本通用的原則，樹立你基本正確的觀念，可是若是隻是死守教條，如何能擁抱日益複雜的變化呢？
你看的教科書，且不說時間上已是二十多年前的了，在適用性上，也不說就是真理，IT 行業發展突飛猛進，幾個月就是滄海桑田，爲了適應這樣的變化，認真地思考、總結、判斷纔是最重要的。
你以爲
「一個沒什麼qps的邊緣接口，竟然作消費者生產者+阻塞隊列的異步模式。顯得你技術少是否是。不知道異步會增長維護成本，提升測試難度嗎？並且，任務隊裏沒有考慮持久化，遇上發佈，丟了好多任務。讀取一個小小的xml和exc配置文件，竟然用流式解析，沒見過這麼二逼的，真是醉了。
你大概不知道，當初跑在你口中的「一個沒什麼qps的邊緣接口」上面的業務帶來了公司曾經 90% 的收入，因此咱們用了複雜的設計以應對當時的需求，固然如今業務轉變，老系統再也不須要處理那麼多業務了，可是更沒有理由爲一個『works perfectly well』而且再也不重要的業務重構代碼吧？
因此，不是咱們秀技術，而是業務需求 + 業務變動使然，年輕人還須要多學習一個。
你抱怨
「作優化全靠拍腦門拍大腿，難道不會用excel分析日誌，用jprofile掃項目？一個100之內的常數集合遍歷，他也要寫個優化算法進去，算法跟業務還攪在一塊兒，一團亂麻。每一個人都在嚷嚷性能、算法、分佈式計算……幾乎沒有文檔，全靠從代碼反推邏輯。有枚舉他不用，非要在每一個頁面上，把枚舉值挨個兒寫死，知道後面改代碼多麼費勁嗎？欺騙性的變量名，裏面存儲的是AES加密的，變量名後綴卻寫成了DES；裏面存的是小寫字母，卻寫成upperStr。一個方法十幾個參數，有三分之一是極其簡略的縮寫，註釋確定也沒有的。一個類寫到三四千行是常事。
我再強調一次——咱們是全中國同類公司中技術能力第一的，你所說的問題，固然是不存在的。
咱們有專門的 Hadoop 集羣來分析日誌，固然也就用不着 Excel 了。
對於咱們這種體量的公司來講，不存在什麼『常數集合』，代碼必須用合適的數據結構——這是常識吧？
特殊的算法和業務摻雜以增長內聚性，這是咱們多年的經驗，的確，它和教科書上說的不同，可是我前面說了，死守教條是不行的——想必你必定知道 OSI 7 層網絡模型吧？
公司的技術氛圍濃厚，是和公司的基因分不開的，咱們公司最重要的原則就是——『擁抱變化』，從十幾年前的機房託管單機到如今的龐大自建集羣，技術躍遷了何止千萬裏，因此每一個人都在學習新知識、每一個人都沉浸在新知識的喜悅中。
你的問題，大多都是由於沒有考慮到公司的龐大致量和十幾年的技術躍遷纔有的疑問，這點再也不贅述，自行體會吧。
你想的是
「開發自測，竟然要把代碼全丟到公共機器上，並且都是走svn，他們把svn當ftp用。svn裏面大量的無心義提交，一多半的提交連都編譯不過去。我看到有個應屆生，改了兩句話，立刻提交，說是怕代碼丟失。一個運行了兩年的項目，spring的包掃描明顯配錯了，有些bean根本掃不進來，竟然沒有人發現。一半的bean在spring管理下，另外一半的bean他們本身寫單例模式來實例化。
其實那不是 SVN，那是咱們公司自主研發的適應咱們內部需求的 源代碼管理系統 和 文件管理系統，你能夠往裏面聽任何東西。
你所說的「無心義提交、一多半的提交連都編譯不過去」其實只是表象，這套系統代號 TITAN，它自帶 CIDD（持續繼承、交付、部署），因此這些沒法編譯的提交都是不會有機會走到下一步流程的的。
若是你工做了一年，你就會發現這個需求是很重要的，改動、尤爲是大型改動，中間會有不少非可用但有須要存檔的步驟，現有的源代碼管理系統都不能很好地支持這些需求，所以你也被教育了一套適應落後工具的思想。人啊，最重要的能力是改進工具，因此用 TITAN 的時候要擁抱全新思惟，不要被落後思惟捆綁。
若是你工做了幾年，你可能還會問爲何咱們沒用 Jenkins、Travis 等工具，其實呀，就在 TITAN 之中呀，它凝結了公司最優秀的人才的十幾年寶貴經驗和心血。
By the way，咱們最近正計劃開源它，爲中國開源社區作貢獻，也但願提升業界的綜合素質。歡迎你提交 PR 哦。
你最後說
「他們用mysql來作審計系統，出報表，有個報表要跑8分鐘。原來是有人用字符串來存多值（逗號分隔），sql裏寫了like，致使沒有利用到索引。爲何不用pg，pg在sql編程方面，功能更豐富，更適合作統計，它自己就支持數組。程序員們都是得過且過的態度，怎麼把代碼灌進去，跑的通測試，就算交差了。爲何大型互聯網公司，技術和管理這麼差勁，是怎麼造成的？
爲何不用 pg？若是你抱着這種想法，那用了 pg 也要被噴的，到時候就就會說 —— 「爲何不用 sqlite，輕量簡單，搞這麼複雜真的有必要嗎？」，真的有必要。。。
這只是一個很簡單的系統，作的事情也很簡單，當初作這個系統的同事更熟悉 MySQL，固然 MySQL 是不二之選了，對於簡單的東西，追求的是開發速度、使用便利性。
你以爲一個月跑一次的審計代碼，8 分鐘有什麼問題嗎？就算是一週跑一次，固然也是沒問題的。
程序員的單位時間是如此寶貴，爲了優化一段一個月跑一次的 8 分鐘代碼，值得花費數天的時間來作這件事嗎？
重複一遍，你的問題，大多都是由於『沒有考慮到公司的龐大致量和十幾年的技術躍遷纔有的疑問』，這點再也不贅述，還請自行體會。
固然，年輕人樂於思考，這是好事，是但願，新鮮血液替換老舊部件系統才能健康發展成長，人如此、公司如此、國家也是如此。
但願你勤于思考，努力學習，有問題的話，咱們公司是鼓勵同事們向 CEO、CTO 寫信的，否則也不會有 CEO、CTO 信箱了你說對嗎？
固然，這樣的技術性問題、你寫給我就好，CEO 是船長，不須要關心底層鍋爐房的細節。
另外我想補充一下個人想法，但願對你有所幫助。
你看你都沒說加班問題，咱們公司沒加班啊，這多好，怎麼作到激烈競爭下還能不加班的？都虧了公司老領導和元老們的一手決策
因此我想補充的不是技術問題，技術問題都不是問題，年輕人能夠學習、交流，技術都會很快成長，畢竟年輕人的衝勁大、頭腦靈活。
我想說的是總體觀、大局觀、大棋戰略。
黃金的導電性最好，爲何電腦主板還要用銅？
清華大學最好，爲何有人要去普通學校？
飛機最快，爲何還有人坐火車？
由於資源都是有限的，咱們在現實生活中——而不是教科書上——必須兼顧成本和產出的平衡。
你問我每行代碼都多人多層人工 review 好很差？問我支不支持？我說好，review 我怎麼能不支持呢？我今天在知乎這個公衆平臺我明確說了我支持。
可是你也應該多學習一個，這個現實畢竟是現實，咱們要兼顧各類考量。
你今天在這裏渲染「大公司技術和管理這麼差勁」，是不對的、是失實的、是欠妥的、是缺少認真思考的、是未加深刻考量的。
未來輿論出了誤差，你雖然不用負責任，可是你認識到本身的錯誤的時候，會後悔、會內疚、會難過的吧？
何處烏托邦？或許……等下一代？
總結就是，生產效率纔是最重要的，世間萬物最重要的是平衡。
怎樣取捨、如何妥協，這不只是大天然的規律，也是咱們前進、發展的準繩和仰仗的原則。
陳萌萌的回答：
地址：www.zhihu.com/question/32039226/answer/75823779
題主你看到了不少槽點，但我認爲你不能只看到槽點和大概怎麼解決。有沒有想過怎麼改進，若是是你的話你怎麼作，這些項目裏面臨的主要挑戰是什麼，次要的挑戰又是什麼？
不要只告訴我技術A弱爆了，用B就能夠完爆這個項目了。**你知道用B的優劣，B的適用場景以及適用B的成本嗎？對於一間公司來講，成本是很重要的。**我這裏說的成本不是金錢。而是，假如你看不爽一份代碼，你打算重構它，你以爲你須要投入多少時間，多少人力？重構以後，又要花費多少時間和人力去升級依賴這份代碼的其餘項目？不要覺得開會無用，老闆就只是在每天發郵件。若是你重構了一份代碼，不能經過溝通說服其餘組去升級他們的組件，又或者你只是重構了一份雖然很醜陋，但其實並無多少程序依賴它的代碼，又又或者你重構了代碼只是讓代碼技術含量更高了，更好看了，卻沒給公司帶來多少收入甚至KPI，那你的工做和成果就很尷尬了。
其實上述也解釋了爲何你身邊的同事都眼睜睜地看着這些醜陋的shit存在而無動於衷。由於他們也是須要投入成本的。先不論他們我的技術水平高低，**試問誰願意挑一個又艱難，又不能產生多少效益的任務去作？**固然，你會說，寫好代碼是程序員的節操。抱歉，節操多少錢一斤，北京三環商品房多少錢一平？
編程高手都有真愛，但現實就是編程高手百裏挑一。咱們身邊的大部分同事可能只是但願養家餬口，他們頭上還掛着十幾個bug等着修。咱們數落他們沒追求，但追求歷來都不是嘴上說說，吐吐槽就能實現的。
人心如此，公司也如是。
矛盾分主次，公司的目標都是同樣的：用最少的成本投入到最能產生效益的項目中去，或者投入大成本去解決公司最須要解決的問題，這間公司才能繼續運做。
因此題主你想一想，在你吐槽的個案中，有多少是公司真正關心的？有哪些是你的老闆認爲能夠創造最大效益的？有哪些纔是主要矛盾或者挑戰須要最牛逼的人自告奮勇第一時間解決？去辨別，解決這些關鍵的問題吧，騷年。必要時帶上（忽悠）一隊人馬（同事）跟你一塊兒幹，苟富貴，勿相忘。不要像祥林嫂同樣，每天抱怨着生活，日日思考着辭職。得罪點說一句：「淪落」到要跟這樣的人共事工做，難道本身身上就沒有緣由？
這個世界有更好的公司，有更牛逼的人。若是你認爲解決這間公司的這堆問題不值得，又或者同事實在太不給力，就遠走高飛吧。
我之前也跟題主同樣，看我第一份正式工做的不少技術環節都至關不爽。這份代碼寫得醜，那個設計像大學生做品，重要的項目竟然連單元測試都沒有……可是我後來反觀我本身，並無發現比起那些醜陋代碼和糟糕實現強悍多少。我跟個人同事沒有質的區別。我笑話他們代碼混亂bug不盡，我未嘗不是少處理了一個field，倒騰錯了一個片斷的數據搞到要翻工重跑？在我心底裏艹了隔壁組那個「個人程序好像不能跑，你幫我debug下」的同事一千次以後，帶我作ML讓我倒騰數據而且被個人程序搞壞了幾份數據（固然後來搞好了）的T9君在會議上說：「她已經很努力了，我認可我有時候也逼得她太緊，她應該有多些時間的。」
我將本身的原創文章整理成了一本電子書，取名《Python修煉之道》，一共 400 頁，17w+ 字，目錄以下：
如今免費送給你們，在個人公衆號後臺回覆 修煉之道 便可獲取。
最後我最近建了一個讀者交流羣，想加入的能夠在公衆號後臺回覆「加羣」便可～
👆掃描上方二維碼便可關注
本文分享自微信公衆號 - Python空間（Devtogether）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。