?學(xué)習(xí)任何一門技術(shù)，在一開始就養(yǎng)成優(yōu)秀的習(xí)慣，這是非常重要的。
1
看官方文檔
遇到不清楚或不懂的知識(shí)點(diǎn)，先去看官方文檔！
很多官方文檔是英文的，硬著頭皮也要看！看著看著就習(xí)慣了。
剛開始讀英文文檔會(huì)費(fèi)時(shí)間和精力，但是等你回過頭來再看，你會(huì)覺得這才是最恰當(dāng)?shù)倪x擇。
為什么這樣講？
且不說你的英文水平得到提升（這是程序員無法回避的問題），耐性得到鍛煉，什么叫官方文檔？！兩個(gè)字：權(quán)威！準(zhǔn)確！當(dāng)你習(xí)慣了在百度上百度一些似是而非，似懂非懂的答案時(shí)，甚至有的文章觀點(diǎn)完全不一樣，你就會(huì)懂了。
當(dāng)然，并沒有否認(rèn)網(wǎng)上有好的答案和文章，我自己也經(jīng)?？磩e人的博客。只是，作為初學(xué)者，你的水平很難去辨別一些文章，觀點(diǎn)的好壞對(duì)錯(cuò)，而這可能會(huì)對(duì)你理解一些知識(shí)帶來致命的誤導(dǎo)！
所以，作為初學(xué)者，應(yīng)該多讀官方文檔，不要浮躁，要知道任何成長(zhǎng)都沒有捷徑！
2
掌握邏輯，遵循統(tǒng)一原則
2.1：不要過分糾結(jié)于“怎樣把代碼寫得更短”或者“把代碼寫進(jìn)一行”。
print filter(lambda x: len(filter(lambda y: x % y == 0, xrange(2, int(sqrt(x) + 1)))) == 0, xrange(2, 100))
這樣的代碼尼瑪意義何在？
2.2：至少在同一個(gè)項(xiàng)目里，遵循統(tǒng)一的命名原則。
class Test(object):
...
class ShuRuTest(Test):
...
class shuchu_ceshi(Test):
..
這真不能忍……
2.3：如果有比較通用的廣為接受的格式標(biāo)準(zhǔn)，請(qǐng)務(wù)必遵守。
比如Python的PEP008，比如C/C++至少有K&R（當(dāng)然還有其它）……諸如此類。
2.4：代碼較長(zhǎng)時(shí)記得寫好注釋，整個(gè)項(xiàng)目寫好文檔。
幾十行的小東西寫個(gè)說明也好；幾百幾千行的不寫注釋維護(hù)起來太麻煩。最可恨是項(xiàng)目沒文檔，別說轉(zhuǎn)手了，就自己過個(gè)小半年再來看都成了互不認(rèn)識(shí)。
2.5：盡量拆分函數(shù)功能及類，保證一個(gè)函數(shù)只做一件事，不要全堆一個(gè)函數(shù)里。
一個(gè)函數(shù)幾百行？一個(gè)函數(shù)六七重循環(huán)？
……
2.6：考慮好異常處理，無論用if還是try。
畢竟一個(gè)RE線程就掛了，盡量考慮全可能的意外情況吧。
2.7：掌握好你所用語言的設(shè)計(jì)邏輯，或者說“世界觀”。
真正學(xué)好用好一種語言所必須的過程。其實(shí)并不復(fù)雜，多寫多總結(jié)很容易就能得到正確的理解，至少抽象層的理解務(wù)必要有。當(dāng)然上手抓著本國人編寫的“xx語言編程實(shí)例”照著抄來抄去然后說哇擦我懂了這種……可能性不是很大。
2.8：出現(xiàn)問題時(shí)，請(qǐng)先懷疑自己的代碼。
在各種社區(qū)里經(jīng)常會(huì)出現(xiàn)這樣的提問：
“你們有誰遇到過這樣的情況嗎？xxxx工作不正常！我的程序絕對(duì)沒有錯(cuò)！”
一口咬定自己程序沒問題，然后直接就開始質(zhì)疑廣泛使用的庫、解釋器有著神奇的無數(shù)人用過都沒有發(fā)現(xiàn)的bug……然后代碼貼出來一看，幾乎99%是他自己代碼里的錯(cuò)誤……
2.9：務(wù)必看懂錯(cuò)誤提示。
其實(shí)是編程的最基本要求，編譯器（解釋器）及運(yùn)行時(shí)給出的錯(cuò)誤提示務(wù)必看懂。其實(shí)沒啥難的，常見的也就那么些個(gè)單詞，就那么幾項(xiàng)概念，看明白就不用帶個(gè)錯(cuò)誤提示滿世界問“我這個(gè)錯(cuò)誤什么意思”這類的問題了……
如果你使用C語言或者C++，小伙伴們也可以在公眾號(hào)后臺(tái)直接回復(fù)筆記，就能找到C和C++的編碼規(guī)范哦。如果是C#，有Resharper插件即可。
3
不炫技
什么叫不炫技？就是能用最通用的方法解決的問題，絕不引入個(gè)人的方法，即使這個(gè)方法能突顯一個(gè)程序員的逼格。
因?yàn)橐粋€(gè)程序員的逼格就意味著別的程序員智商被碾壓，更多的程序員沒法維護(hù)你的這段代碼。而讓一段代碼規(guī)范且可讀，是一個(gè)團(tuán)隊(duì)程序員的最基本的責(zé)任。
開源項(xiàng)目不是版本越新越好；
別人寫的代碼也不一定都是垃圾，不一定非要自己重構(gòu)一遍；
不是所有模塊都套上某個(gè)設(shè)計(jì)模式才能開發(fā)；
做優(yōu)化模型的時(shí)候，不是越復(fù)雜越高大上的模型越好用，有時(shí)候組合優(yōu)化和邏輯回歸就能解決很多工程問題；
中小項(xiàng)目里泛型不是用的越多越好；
Scala的程序員不好招，Spark的項(xiàng)目沒必要都用Scala寫；
網(wǎng)站也不是都一定用node.js寫才不過時(shí)。
在最合適的項(xiàng)目上用最合適的技術(shù)，不炫技，是程序員最好的習(xí)慣。
4
重視模塊化，重視抽象但不濫用
一般來說，程序員在2k行、20k行、200k行等若干程序規(guī)模時(shí)會(huì)遇到瓶頸，如果不用更科學(xué)有效的方法，超過了這個(gè)行數(shù)代碼就會(huì)混亂到難以維護(hù)。
針對(duì)這一現(xiàn)象，一個(gè)在編程方面很有成就的人做過一些實(shí)驗(yàn)。在很不認(rèn)真的寫一些小程序時(shí)，也總是寫的混亂不堪，這種情況下，程序行數(shù)超過200行就覺的很難受了
在需要進(jìn)行一點(diǎn)小的修改時(shí)，往往需要花很長(zhǎng)時(shí)間去尋找到底該改哪里，十分吃力——這種吃力感是在那些精心思考的大項(xiàng)目里從未感受過的。這說明了，并沒有人有過人的天賦能在混亂中輕易找出清晰的脈絡(luò)，那就是說，能如魚得水，是因?yàn)楹玫牧?xí)慣。
后來，進(jìn)行了深入的思考。在模塊劃分合理、抽象合理的程序里，可以簡(jiǎn)單的把一個(gè)個(gè)功能抽象為一個(gè)簡(jiǎn)單的黑盒，不需要知道他們內(nèi)部發(fā)生了什么復(fù)雜的反應(yīng)，只需要知道他們對(duì)什么樣的輸入會(huì)做出什么樣的輸出。
這種抽象極大的減輕了大腦的負(fù)擔(dān)，可以把精力更多的投入到真正需要考慮的地方。而那些混亂的程序里，需要理清每一句話之間的關(guān)系，這無疑會(huì)極大的消耗腦力。這種情況下，200行就渾身難受就可以理解了——因?yàn)橛糜诰S護(hù)項(xiàng)目關(guān)系所消耗的腦力已經(jīng)遠(yuǎn)遠(yuǎn)大于了那些好程序里的消耗。
這個(gè)習(xí)慣，真的讓人十分受益，請(qǐng)一定堅(jiān)持。剛開始的時(shí)候，你或許覺得花很長(zhǎng)時(shí)間去思考程序的模塊劃分、抽象層級(jí)是十分浪費(fèi)時(shí)間的無用功；但久了以后，你就會(huì)感受到這種習(xí)慣帶來的好處：它會(huì)在無聲無息之間幫你消除掉許多瓶頸。而且還有額外的好處：當(dāng)你習(xí)慣用模塊化組織你的思維時(shí)，思維能力也會(huì)有一定的增強(qiáng)。
好的習(xí)慣是成功的開始，從一開始就值得堅(jiān)持。
