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