從校園到職場測驗

　　我們每個人都是從校園走向職場，那么從校園走向職場需要注意什么問題呢，有哪些經(jīng)驗需要借鑒呢，下面是學(xué)習(xí)啦小編為你整理相關(guān)的內(nèi)容，希望大家喜歡!

　　我們先說職場上所謂技術(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é)印度，學(xué)開發(fā)規(guī)范;覺得印度在IT方面領(lǐng)先中國很遠(yuǎn)，但是發(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)變，作為定制開發(fā)，強(qiáng)調(diào)需求確認(rèn)，強(qiáng)調(diào)定稿，但是這種模式在互聯(lián)網(wǎng)時代是自尋死路，你必須能隨時跟著需求走，跟著時代的潮流前進(jìn)，你如果按照所謂的瀑布流去做項目，你做互聯(lián)網(wǎng)，你必然沒有機(jī)會，我剛畢業(yè)的時候，也遇到這個問題，領(lǐng)導(dǎo)說，好好學(xué)軟件工程，今天我可以明確的告訴大家，在互聯(lián)網(wǎng)時代，軟件工程里的所有開發(fā)思想，除了敏捷開發(fā)值得學(xué)習(xí)外，其他的都可以不用再考慮! 如果你還認(rèn)為你的開發(fā)需要明確的邊界條件，明確的需求確認(rèn)，明確的發(fā)展路線，請離開這個行業(yè)。

　　所以，問題就出來了，一個產(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ù)載均衡的時候，這個第三范式無法滿足快速擴(kuò)展的需求。

　　所以很多時候，教科書上的一些范例，方法，并不適應(yīng)新的業(yè)務(wù)需求和應(yīng)用場景，而此時，就會被只讀過教科書的孩子們認(rèn)為是，代碼太爛，技術(shù)太遜。

　　4、技術(shù)演進(jìn)中的印跡

　　一個多年運營的系統(tǒng)，在演進(jìn)的過程中，會存在大量不同的參與者，每個參與者都會有自己的邏輯，想法，以及處理的方式，那么在代碼迭代中，技術(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ù)器來支撐，而收效確是，可以每周生成報表的時候從幾十分鐘縮短到幾秒鐘，那么，如果你是老板，你會同意這樣的方案么?

　　沒有全局觀，只從局部去看設(shè)計，就會自以為是的認(rèn)為別人做的很爛，很垃圾。

　　6、資源緊缺的作品

　　大公司也會資源緊缺么?至少人力資源一直是緊缺的，比如有個緊急的活動，有個緊急的任務(wù)，時間特別急，程序員只好急急忙忙從第三方開源軟件抓了一段代碼，改吧改吧塞進(jìn)去了，反正業(yè)務(wù)滿足了，至于不好那也實在沒時間了，結(jié)果這個臨時活動效果不錯，于是慢慢成為常態(tài)活動，而這個工程師又去干別的去了，這個代碼反正也沒出錯，那就一直跑著唄，新人來一看，這啥玩意啊，代碼東一榔頭西一棒槌，這程序員不會設(shè)計系統(tǒng)么?拜托，站著說話不腰疼，真沒時間設(shè)計。

　　那么，下面要說，新人就不能提出現(xiàn)有系統(tǒng)的問題么?就不能提出改進(jìn)的方案和建議么?

　　當(dāng)然可以，你進(jìn)入一個企業(yè)就是干這個的，公司花錢養(yǎng)你就是讓你來改進(jìn)系統(tǒng)提升業(yè)務(wù)支撐能力的。但是，這需要有一個正確的認(rèn)識和思路在前面。

　　第一，盡可能更完整的了解系統(tǒng)，查看一套代碼的時候，了解所謂的爛和不好的起因是什么，歷史演進(jìn)的過程是什么，了解其在業(yè)務(wù)系統(tǒng)中的地位和價值是什么，有了一些認(rèn)識和理解后，再來思考所謂好和不好的問題。

　　第二，從一個最有把握，結(jié)構(gòu)最簡單的地方入手，用你認(rèn)為正確的方式修改一個最小的結(jié)構(gòu)，然后通過測試，發(fā)布的流程，然后通過運維和其他主管人員獲得反饋，了解改進(jìn)是否具備對舊版本的比較優(yōu)勢，以及比較優(yōu)勢究竟有多大，多重要。不重要沒關(guān)系，但是你要了解是否這個改進(jìn)是正確的;完成第一個后，努力去完成第二個，當(dāng)你能夠順利發(fā)布完成十個或更多的這樣的改進(jìn)和優(yōu)化，并確認(rèn)你的代碼比較優(yōu)勢確實明顯的時候，再來談別人的代碼爛不爛的問題，如果你這些都做到了，不需要你來談，你的主管會看得到的。

　　第三，輕易不要談重構(gòu)，輕易不要談重構(gòu)，輕易不要談重構(gòu)

　　必須說三遍

　　我講過一個架構(gòu)悖論，某些巨頭的技術(shù)架構(gòu)就出現(xiàn)過，為了滿足所謂高擴(kuò)展性的原因，開發(fā)人員做了一個特別復(fù)雜的邏輯關(guān)系特別龐雜的系統(tǒng)，他們說這個系統(tǒng)多花點時間是值得的，因為以后你有新的需求可以靈活擴(kuò)展了!于是產(chǎn)品人員和運營耐心等待。

　　新系統(tǒng)上線后，市場發(fā)生了一些變化，新的熱點出現(xiàn)，運營人員說，我們能不能增加一些你看那個那個，那個那個功能。技術(shù)人員說，對不起，這個需求在我們設(shè)計的初期完全沒有考慮到，因為現(xiàn)在架構(gòu)太復(fù)雜了，所以這個版本肯定不能支持，你放心，下次重構(gòu)的時候我們會考慮的。

　　我對架構(gòu)的原則是，適度靈活，簡單至上，你會發(fā)現(xiàn)，越是簡單的架構(gòu)，遇到新的業(yè)務(wù)需求，改動和升級越容易，很簡單的一個道理，新的工程師進(jìn)來看代碼理解邏輯的成本低。所謂照顧更多的需求可能性，這么說吧，人家設(shè)計了開發(fā)語言，就是照顧更多需求的可能性，你難道也要設(shè)計一款開發(fā)語言?

　　再說一個我一直特別想吐槽的地方，php之所以被發(fā)明并且被快速傳播，成為流傳最廣的語言，是因為腳本語言是滿足需求最快最簡單的方法，門檻極低，開發(fā)測試極為簡單方便，但是現(xiàn)在一堆人搞各種php框架，好像不做框架就不是php開發(fā)一樣，我就不明白了，你想搞框架你用php干嘛啊，人家好不容易把事情弄簡單了，你又咔嚓咔嚓弄回去了，我現(xiàn)在看著那些所謂可以靈活擴(kuò)展的框架就頭大，簡直是莫名其妙，最后就是學(xué)習(xí)成本極大增加，調(diào)試成本極大增加，優(yōu)化成本極大，極大，極大增加，面對高并發(fā)場景，優(yōu)化難度比原生態(tài)開發(fā)高了不止一個數(shù)量級。 當(dāng)然，這個是題外話，和今天主題無關(guān)。

　　回到重構(gòu)話題

　　徹底理解業(yè)務(wù)邏輯，盡可能做到360度無死角理解各種業(yè)務(wù)邏輯之間的關(guān)系，(如果你處于巨頭公司，能做到這一點幾乎可以封神!)

　　徹底理解當(dāng)前架構(gòu)的演進(jìn)過程(中間踩了多少坑，有多少發(fā)展中的問題都是怎么解決的，如果不理解，請相信我，你絕對會再踩一遍!)

　　徹底理解各個模塊的調(diào)用關(guān)系和彼此的依存關(guān)系。

　　徹底理解當(dāng)前架構(gòu)的瓶頸和問題。(前提是必須知道這個架構(gòu)為什么能work，否則這個理解等于不理解!)

　　然后再去談重構(gòu)的話題。

　　最后一點，強(qiáng)調(diào)一下，問題即機(jī)會

　　如果你發(fā)現(xiàn)一個巨頭依然存在很多技術(shù)上連你都覺得不對的問題，你應(yīng)該高興才對，這不是你的機(jī)會么?但是你要明白，哪些是真的問題，哪些是你涉世不深的誤會，你一步步解決這些問題，在解決過程中一步步理解系統(tǒng)，到一定程度，你會明白更多，理解更深;只是站出來喊，這些垃圾那些垃圾，只能暴露你的淺薄和無知。 又要重復(fù)那句可能掉友善度的話，別做教科書般的SB。