大家好，雖不是行業(yè)大牛找個(gè)機(jī)會(huì)和大家隨便聊聊。我這次不寫那些方法論或者是感受的東西，這些可能大家get不到，也未必喜歡。這次寫一點(diǎn)實(shí)際的，只要照著做，基本上不會(huì)被認(rèn)為是個(gè)菜鳥，在職場當(dāng)中也不會(huì)踩雷。
相信小習(xí)慣的力量
python菜鳥和大牛的區(qū)別除了寫代碼、debug的核心能力差距之外，另外一個(gè)很大的差別就是在習(xí)慣上。大牛經(jīng)過摸爬滾打練出了一系列優(yōu)良的習(xí)慣，而菜鳥好習(xí)慣還沒養(yǎng)成，壞習(xí)慣有了一堆。所以身為菜鳥的時(shí)候一定要有規(guī)范和習(xí)慣意識(shí)，養(yǎng)成好習(xí)慣，去掉壞習(xí)慣讓自己越來越習(xí)慣寫出優(yōu)質(zhì)的代碼。
關(guān)于習(xí)慣仁者見仁，每個(gè)人也都有自己的習(xí)慣。我簡單提幾個(gè)，給大家拋磚引玉。
1.一個(gè)函數(shù)只做一件事
如果有一天你接手了另外一個(gè)同事的代碼，發(fā)現(xiàn)他有一個(gè)函數(shù)里面裝了三千行代碼，你會(huì)是什么感受？
這是我親身的經(jīng)歷，我當(dāng)時(shí)看到代碼的第一反應(yīng)就是把這個(gè)人揪出來暴打一頓。代碼和其他文本信息不同，越擁擠可讀性越差。優(yōu)質(zhì)的代碼和優(yōu)質(zhì)的文章很像，結(jié)構(gòu)清晰、層次分明、表達(dá)準(zhǔn)確。一個(gè)函數(shù)里面裝幾千行代碼顯然是老太太的裹腳布——又臭又長。
對于一個(gè)函數(shù)里究竟應(yīng)該寫多少代碼，每個(gè)人有不同的理解。實(shí)際上我們也沒必要硬扣，遵守一個(gè)簡單的原則即可——一個(gè)函數(shù)只做一件事。舉個(gè)簡單的例子，假設(shè)我們要從上游讀一批數(shù)據(jù)，然后畫出某一個(gè)函數(shù)作用之后的結(jié)果。我們簡單分析一下，表面上是畫圖這一件事情，但是這一件事情當(dāng)中其實(shí)包含了好幾個(gè)步驟，比如說從上游獲取數(shù)據(jù)，獲得函數(shù)作用的結(jié)果，最后才是畫圖。那么我們完全可以拆分成三個(gè)函數(shù)，一個(gè)函數(shù)獲取數(shù)據(jù)，一個(gè)函數(shù)獲取結(jié)果，一個(gè)函數(shù)畫圖。
這樣別人以及以后的自己看這段代碼就會(huì)非常清楚，每個(gè)函數(shù)做了什么一目了然。假如有一天老板無意間翻了大家的代碼，別人的代碼一個(gè)函數(shù)里裝了幾千行，你的代碼層次分明，每個(gè)函數(shù)做什么都一目了然，你說老板會(huì)怎么想？
2.起長一點(diǎn)的變量名
新手一個(gè)很大的問題就是總喜歡起很短的變量名，像是a,b,c,d?；蛘呤鞘裁碽d,aa什么的，看起來非常難看，可讀性也很差。之前有幾個(gè)同學(xué)找我?guī)退麄兛创a，給的都是這種代碼，看起來感覺眼睛都被針扎了……
吐槽歸吐槽，老實(shí)說我在之前打acm的時(shí)候也是喜歡短變量名，雖然不至于這么夸張，但一般一個(gè)變量名也不會(huì)很長。當(dāng)然這是由于當(dāng)時(shí)比賽的需要，大家爭分奪秒，別人一個(gè)變量名叫btn，你叫binary_tree_node，很顯然拼敲代碼的速度你一定輸。
但問題是后來畢業(yè)了之后我也一直保留這樣的風(fēng)格，不出意外地遭到了老板和同事的毒打。大家都表示不喜歡我這樣的代碼風(fēng)格，我當(dāng)時(shí)還堅(jiān)持，覺得是自己代碼能力的體現(xiàn)。后來去讀了一下一些大牛的代碼，嘗試換了一種風(fēng)格之后，發(fā)現(xiàn)真香了。雖然寫起來的時(shí)候麻煩了一點(diǎn)（其實(shí)也還好，現(xiàn)在有各種代碼補(bǔ)全功能），但是讀起來是真的很舒服，思路也清楚了很多。所以如果你現(xiàn)在的代碼不是這種風(fēng)格的話，請一定嘗試改一下，對自己對其他人都好。
另外一點(diǎn)是我們起名的時(shí)候可以是不規(guī)范的英文，哪怕不太準(zhǔn)確也沒問題，但一定一定不要用拼音。類似用：fenbianlv等作為代碼。
拼音閱讀起來比半通不通的英文還要費(fèi)勁，而且用拼音做變量或者是函數(shù)名是一件非常非常low的事情，絕對會(huì)讓對方對你的能力產(chǎn)生懷疑。市面上也有一些幫助起名的插件，有這方面需求的同學(xué)請務(wù)必去了解一下。
3.遵守代碼規(guī)范
在新手的意識(shí)里可能沒有代碼規(guī)范這個(gè)詞，但是這個(gè)確實(shí)是從新手走向進(jìn)階的必經(jīng)之路。
不同的語言的規(guī)范是不同的，比如說Java和go當(dāng)中流行駝峰命名法，所有變量都是駝峰的。而Python可能只有類名是駝峰的，普通變量和包名傾向于全小寫用下劃線分割。當(dāng)然代碼規(guī)范并不僅僅是命名規(guī)范而已，還有很多很多的規(guī)范。比如中間件的使用規(guī)范、多線程的開發(fā)規(guī)范、數(shù)據(jù)庫的使用規(guī)范等等。
為什么我們要遵守這些規(guī)范？因?yàn)槲覀兊拈_發(fā)工作并不是實(shí)現(xiàn)功能就完事了，以后還需要拓展和維護(hù)。遵守規(guī)范不僅可以不給以后的自己以及他人埋雷，更重要的是可以讓自己的代碼質(zhì)量更高，更加專業(yè)。而且一些規(guī)范當(dāng)中往往是藏著道理的，為什么套接字、線程以及數(shù)據(jù)庫連接都需要維護(hù)一個(gè)“池”？這里面肯定是有門道的，不然為什么大家不怎么簡單怎么來？我們在遵守這些規(guī)范的時(shí)候也能便于我們更好地理解各個(gè)場景當(dāng)中的原理以及細(xì)節(jié)，這也是技術(shù)實(shí)力的一部分。
當(dāng)然我們一開始未必能做得很好，但代碼規(guī)范并不是很困難的事情，從我們有這個(gè)意識(shí)到做到遵守規(guī)范并不需要很多時(shí)間，但是帶來的收益卻是非常豐厚的。之前在前公司，有聽說過過因?yàn)榇a風(fēng)格太差被老板給了差績效的事情，我覺得挺冤枉的，可能就是一時(shí)疏忽給老板留下了差印象，如果當(dāng)時(shí)寫代碼的時(shí)候能注意一點(diǎn)，完全可以避免，代碼有些太大了。
會(huì)用不等于懂了
如果你是應(yīng)屆生，那么當(dāng)你畢業(yè)進(jìn)入職場，你必然會(huì)面臨一個(gè)適應(yīng)的問題。別的我們不提，單單只說技術(shù)方面。我們勢必需要快速學(xué)習(xí)一些我們之前沒有見過或者是不了解的技術(shù)，來應(yīng)付工作當(dāng)中的任務(wù)以及挑戰(zhàn)。
這個(gè)是非常正常的，我想絕大多數(shù)程序員在剛畢業(yè)的時(shí)候都經(jīng)歷過，我自己也不例外。剛畢業(yè)的幾個(gè)月是最辛苦的，我們需要承擔(dān)很大的壓力，對于轉(zhuǎn)變之后的生活也不是完全適應(yīng)。但當(dāng)幾個(gè)月過去，我們適應(yīng)了生活，學(xué)會(huì)了一些基本的技能可以應(yīng)付或者說勝任當(dāng)下的工作之后，一個(gè)潛在的陷阱就到來了。
有一些人會(huì)不知不覺地停止學(xué)習(xí)，因?yàn)樗呀?jīng)足夠應(yīng)付工作了。在工作當(dāng)中他會(huì)有一種在這個(gè)領(lǐng)域我當(dāng)下會(huì)的技能已經(jīng)足夠了的錯(cuò)覺，有些人甚至?xí)虼擞X得其他資歷更深的同事也不過如此，似乎并沒有比自己多會(huì)多少東西。我當(dāng)初就是這樣，因?yàn)槲野l(fā)現(xiàn)我工作當(dāng)中用到的東西玩的非常溜，用起來得心應(yīng)手。我一度有些膨脹，覺得自己已經(jīng)算是一個(gè)經(jīng)驗(yàn)豐富的程序員了。直到后來有一次面試，被問到了一個(gè)常用的工具的技術(shù)細(xì)節(jié)，我張口結(jié)舌一句話也說不上來，我才發(fā)現(xiàn)，自己知道的只是皮毛而已，甚至連皮毛都算不上。
當(dāng)然我們工作當(dāng)中對很多技術(shù)的要求都只是會(huì)用，你會(huì)用就夠了，這并沒有問題。我也并不覺得每一門我們用到的技術(shù)都需要去刨根究底，但我們需要對我們的實(shí)力有清醒的認(rèn)識(shí)，哪些是勉強(qiáng)會(huì)用的？哪些是真正了解掌握的？哪些是需要掌握但是只是勉強(qiáng)會(huì)用的？
能夠想明白這些問題可以讓我們保持一個(gè)清醒的頭腦，對自己的當(dāng)下的處境以及長遠(yuǎn)的發(fā)展目標(biāo)都會(huì)有一個(gè)清楚的認(rèn)識(shí)。
積累知識(shí)而不僅是經(jīng)驗(yàn)
新手或者是小白有一個(gè)特點(diǎn)就是往往更加依賴經(jīng)驗(yàn)而不是知識(shí)，舉個(gè)例子吧。比如新手后端經(jīng)常遇到的問題之一就是maven package失敗，很多人解沖突的辦法就是mvn clean & mvn install。也就是清空重新建立，因?yàn)榇蟛糠智闆r下這個(gè)命令可以解決問題。所以很多新手就記住了這個(gè)命令，每次遇到maven失敗就這么來一次。
如果這個(gè)命令解決不了呢？這些人可能會(huì)換個(gè)命令試試。如果常用的解決問題的命令都試過了還是不行呢？這些人可能就僵住了，覺得這個(gè)問題解決不了了，得請大牛來看了。
這里的核心問題是新手積累的是經(jīng)驗(yàn)而不是知識(shí)，他們只是簡單機(jī)械地把出現(xiàn)的問題和解決方法做映射而已，并不是從原理和核心層面理解問題出現(xiàn)以及解決方案生效的原因。那么帶來的結(jié)果就是，積累到的只是經(jīng)驗(yàn)，下次能解決問題不是因?yàn)閷W(xué)會(huì)了問題的解決方法，也不是理解了這一塊技術(shù)內(nèi)容，只是單純地記住了而已。這顯然也是一種偽成長。
其實(shí)我之前也遇到過這樣的問題，雖然我每次都有意識(shí)遇到問題記錄下解決的辦法，這樣下次就可以不用請教別人了。然而雖然我記錄的問題越來越多，但是每次遇到新的問題還是解決不了，需要請教別人。直到有一天，被我問的大牛露出了不耐煩的神情，才讓我下定決心自己學(xué)會(huì)解決問題。
于是我不再是頭痛醫(yī)頭腳痛醫(yī)腳地解決問題，而是去學(xué)習(xí)了一下問題背后的原理和機(jī)制，再從報(bào)錯(cuò)日志上分析錯(cuò)誤產(chǎn)生的原因，思考解決方案，最終徹底學(xué)會(huì)了解決這一類問題的方法。之后不但能夠自己獨(dú)立解決問題，而且還可以去幫助別人了。我后來回過頭來想想，如果我第一次遇到問題的時(shí)候就自己嘗試去學(xué)習(xí)其中的機(jī)制，而不只是記住解決方法，應(yīng)該可以做得更好。
少說廢話，多寫代碼
著名的Linux之父Linus有一句名言：talk is cheap show me the code。翻譯過來就是廢話少說，代碼拿來。我覺得這句話非常符合這一行的精髓，我們不是靠嘴皮子吃飯的，而是靠實(shí)實(shí)在在的產(chǎn)出，這個(gè)產(chǎn)出最終是要落實(shí)到代碼上的。作為一個(gè)新人，可能我們會(huì)有這樣的問題，那樣的困惑。然而這許多的問題和困惑我們光想是沒用的，只能用硬實(shí)力來解決。
著名的C語言作者譚浩強(qiáng)也有一句名言：新手學(xué)編程最應(yīng)該做的事情就是寫滿一萬行可以運(yùn)行的代碼，之后你就自然入門了。道理其實(shí)也是一樣的，少說廢話，多做實(shí)事。多做多練，實(shí)力自然不會(huì)差?？障氪当剖浅刹涣舜笈５?。所以如果你猶豫想要學(xué)習(xí)一門新的領(lǐng)域，但是不知道從何做起的時(shí)候，不妨想想這句話，別管它三七二十一，先搞起來寫起代碼來再說。搞著搞著，你自然就明白后面應(yīng)該怎么做了。
以上就是我自己積累的一些思考和想法，如果你是一個(gè)小白的話，希望它能夠幫助你順利度過新手期，向著大牛的目標(biāo)進(jìn)發(fā)。
