不知道你有沒有過這樣的經(jīng)歷：剛剛進入職場時，進入公司實習(xí)，沒多久就發(fā)現(xiàn)，為什么公司的技術(shù)也這么爛啊，啪啪啪，隨意就能指出十幾個問題來。
我們當(dāng)初四十幾個同學(xué)大四集體去北京找實習(xí)單位，當(dāng)時學(xué)校把我們集體安排住在一棟排屋里面，我們工作之后下班經(jīng)常坐在一起閑聊，聊的最多就是吐槽自己的公司代碼很爛，當(dāng)然也包括進入BAT公司的同學(xué)。
一、為什么我公司的技術(shù)這么“爛”？
五年過去了，當(dāng)我最次回想當(dāng)年的閑聊時，狂笑當(dāng)年的我們Too Young Too Naive。
你只看到了爛的表面，而背后的邏輯和原因思考過沒？大學(xué)里學(xué)到的所有典型的策略、算法、邏輯，在職場里，只是最基本的一些東西，甚至可能是已經(jīng)被顛覆的東西，比如數(shù)據(jù)結(jié)構(gòu)里強調(diào)的第三范式在高并發(fā)場景中早就被摒棄了，也就是你即便在課程里得到了滿分，你來到職場，依然可能是菜鳥一名。因為你所面臨的場景、業(yè)務(wù)環(huán)境、需求變更的頻次，和你在學(xué)校里學(xué)到的完全不同。
那么是不是說你就不能發(fā)現(xiàn)職場的問題呢？當(dāng)然不是！我們先來說說職場上所謂技術(shù)問題是哪些原因造成的。
1、年代久遠(yuǎn)，菜鳥的產(chǎn)品
巨頭也是從初創(chuàng)公司起步的，在起步之初，可能技術(shù)實力也不是很好，而且我們知道信息技術(shù)成長性很快，現(xiàn)在我們司空見慣的一些東西在十年前還屬于無人知曉的黑科技，在這種情況下，一個持續(xù)運營的公司，多少會有一些歷史上很粗糙和菜鳥的代碼，并且可能部分仍在運營，這是正常的。
那么為什么會仍在運營呢？說明這個東西雖然不夠好，不夠正確，但是一直沒有出大的問題，沒有給系統(tǒng)添太多麻煩。所以，雖然這個東西不好，但是基于以業(yè)務(wù)為核心的訴求，企業(yè)技術(shù)部門并不是特別有解決的意愿和動力。
2、需求迭代的產(chǎn)物
和教科書不同，職場上的需求是瞬息萬變的，一些初入職場的人會覺得公司需求經(jīng)常改，要求 經(jīng)常變，無法接受，覺得是不規(guī)范、不健康的表現(xiàn)。 15年前，乃至20年前，我們說印度軟件業(yè) 最為發(fā)達(dá)，其開發(fā)流程最為規(guī)范，當(dāng)時很多中國企業(yè)去印度，學(xué)開發(fā)規(guī)范，覺得印度在 IT方面 遠(yuǎn)遠(yuǎn)領(lǐng)先中國。但是發(fā)展到今天，在互聯(lián)網(wǎng)大潮中，請問哪個互聯(lián)網(wǎng)公司還會去印度取經(jīng)學(xué)習(xí) 開發(fā)流程和規(guī)范？請問誰還會說印度比中國在互聯(lián)網(wǎng)研發(fā)領(lǐng)域領(lǐng)先？問題在哪里呢，中國互聯(lián)網(wǎng)產(chǎn)業(yè)之所以發(fā)展快就在于沒有包袱，敢想敢干，隨需應(yīng)變。傳統(tǒng)軟件工程領(lǐng)域里，印度可以 作為定制開發(fā)的楷模，強調(diào)需求確認(rèn)，強調(diào)定稿，但是這種模式在互聯(lián)網(wǎng)時代是自尋死路，你 必須能隨時跟著需求走，跟著時代的潮流前進。在互聯(lián)網(wǎng)行業(yè)，很多開發(fā)往往是沒有明確的邊界條件，也沒有明確的需求確認(rèn)。
所以， 對于一個產(chǎn)品，最初設(shè)計的目標(biāo)是A，但是開發(fā)過程中突然發(fā)現(xiàn)B才是真正的目標(biāo)，而好不容易把開發(fā)一半的目標(biāo)A的系統(tǒng)轉(zhuǎn)為目標(biāo)B，上線之后又發(fā)現(xiàn)需要兼容C和D的目標(biāo)。所以，新人不了解這個背景，這個迭代的歷史，就會覺得，這系統(tǒng)誰設(shè)計的，邏輯怎么都是擰著的？沒辦法，小步快跑，不斷試錯，不斷調(diào)整，快速迭代，就是這樣過來的。
3、所謂的正確的架構(gòu)，存在著你所不知道的坑
就好比前面說的第三范式，新人一看，數(shù)據(jù)結(jié)構(gòu)各種冗余，你怎么不會第三范式啊，大學(xué)課程啊，因為他不知道涉及分布、涉及負(fù)載均衡的時候，這個第三范式無法滿足快速擴展的需求。所以很多時候，教科書上的一些范例、方法，并不適應(yīng)新的業(yè)務(wù)需求和應(yīng)用場景，而此時，就會被只讀過教科書的孩子們認(rèn)為是，代碼太爛，技術(shù)太遜。
4、技術(shù)演進中的印跡
一個多年運營的系統(tǒng)，在演進的過程中，會存在大量不同的參與者，每個參與者都會有自己的邏輯、想法，以及處理的方式。那么在代碼迭代中，技術(shù)的迭代往往是優(yōu)先考慮最緊迫的任務(wù)，優(yōu)化最耗費資源的模塊，在不斷迭代中，代碼的一致性和結(jié)構(gòu)的一致性可能就無法維持，導(dǎo)致一些本來架構(gòu)優(yōu)美的結(jié)構(gòu)可能只剩下兩三個模塊，但是新人就覺得，這模塊做得好復(fù)雜，好啰嗦，很多沒意義的東西塞在里面。請相信我，再優(yōu)美的技術(shù)結(jié)構(gòu)，經(jīng)過幾茬這樣的迭代，都會變得面目全非，雜亂無章。然后等待下一個神做整體的重構(gòu)。
5、側(cè)重點不同的考量問題
比如說，新人發(fā)現(xiàn)一個報表系統(tǒng)效率很低，耗時很長，于是嘲笑，連索引都不會嗎，這么爛的結(jié)構(gòu)怎么設(shè)計的？但是他不知道的是，這個數(shù)據(jù)結(jié)構(gòu)首先要滿足一個非常巨量的每日數(shù)據(jù)新增，而后才要滿足每周一次的報表生成。那么，如果按照他認(rèn)為生成報表的優(yōu)美結(jié)構(gòu)來設(shè)計，所增加的索引和數(shù)據(jù)字段的設(shè)計，就會日常帶來大量的i/o開銷，數(shù)據(jù)新增的邏輯就會導(dǎo)致額外幾倍十幾倍的開銷，也就是說需要很多臺額外的服務(wù)器來支撐，而收效卻是，可以每周生成報表的時候從幾十分鐘縮短到幾秒鐘，那么如果你是老板，你會同意這樣的方案嗎？
6、資源緊缺的作品
大公司也會資源緊缺嗎？至少人力資源一直是緊缺的，比如有個緊急的活動，有個緊急的任務(wù)，時間特別緊，程序員只好急急忙忙從第三方開源軟件抓了一段代碼，改改塞進去了，反正業(yè)務(wù)滿足了，至于不好那也實現(xiàn)沒時間了，結(jié)果這個臨時活動效果還不錯，于是慢慢成為常態(tài)活動，而這個工程師又去干別的去了，這個代碼反正也沒出錯，那就一直跑著。新人來一看，這啥玩意啊，代碼東一榔頭西一棒槌，這程序員不會設(shè)計系統(tǒng)嗎？
二、我應(yīng)該怎么樣解決這些爛代碼？
你要明白，哪些是真的問題，哪些是你涉世不深的誤會，不要只是站出來喊，這些垃圾那些垃圾，這只能暴露你的淺薄和無知。
那么，新人就不能提出現(xiàn)有系統(tǒng)的問題嗎？就不能提出改進的方案和建議嗎？當(dāng)然可以！但是，這需要有一個正確的認(rèn)識和思路在前面。
1、盡可能更完整地了解系統(tǒng)，查看一套代碼的時候，了解所謂的不好的起因是什么，歷史演進的過程是什么，了解其在業(yè)務(wù)系統(tǒng)中的地位和價值是什么，有了一些認(rèn)識和理解后，再來思考所謂好和不好的問題。
2、從一個最有把握，結(jié)構(gòu)最簡單的地方入手，用你認(rèn)為正確的方式修改一個最小的結(jié)構(gòu)，先通過測試、分布的流程，然后再通過運維和其他主管人員獲得反饋，了解改進是否具備對舊版本的比較優(yōu)勢，以及比較優(yōu)勢究竟有多大，多重要。不重要沒關(guān)系，但是你要了解是否這個改進是正確的；完成第一個后，努力去完成第二個，當(dāng)你能夠順利分布完成十個或更多的這樣的改進和優(yōu)化，并確認(rèn)你的代碼比較優(yōu)勢確實明顯的時候，再來吐槽別人的代碼的問題。
3、如果你這些都做到了，你可能就不屑于吐槽別人的爛代碼啦，因為你會把它們當(dāng)作一個個小怪獸。
三、一些說明
最近在讀曹大的《你憑什么做好互聯(lián)網(wǎng)》這本書，書中很多內(nèi)容寫出了我初入職場時的心態(tài)和做法，這些曾經(jīng)經(jīng)歷過的事不吐不快，本文內(nèi)容基于書上的做了一些修改。
謝謝你的閱讀，愿初入職場的你少點吐槽，多了解點真相。愿曾經(jīng)也吐槽過的你，和我一起一笑而過。
