01
關(guān)于馬化騰編碼的水平，網(wǎng)絡(luò)上曾有這樣一個(gè)段子：
曾經(jīng)和pony（馬化騰）一起寫過代碼。當(dāng)時(shí)我、pony、馬克3人擠在一個(gè)只有10個(gè)位置的房間里，埋頭開發(fā)。馬克當(dāng)時(shí)負(fù)責(zé)排查兩個(gè)bug，跟進(jìn)了10個(gè)月，沒有一點(diǎn)進(jìn)展，下樓準(zhǔn)備買點(diǎn)瑞士卷吃，消消愁。回來發(fā)現(xiàn)pony光著膀子，啃著個(gè)豬蹄兒，站在陽臺(tái)，望著寂靜的夜，回頭冷靜地和馬克說了句：“bug我?guī)湍闾幚砗昧恕！?/p>
可見老馬的編碼水平之高，當(dāng)然，這只是個(gè)段子。但據(jù)說當(dāng)年創(chuàng)業(yè)時(shí)，公司主頁是馬化騰自己親手制作的。
關(guān)于他編碼是不是最好的，我們不知道；但可以肯定的是，他一定是通過軟件掙錢掙得最多的那位程序員。
02
無獨(dú)有偶，互聯(lián)網(wǎng)界的精英，大多數(shù)是技術(shù)出身，譬如雷軍、李彥宏、周鴻祎等，幾乎都是編程高手。作為京東首席CEO，劉強(qiáng)東編碼水平也備受關(guān)注。
知乎上，有人曾提問過這樣一個(gè)問題：
劉強(qiáng)東的代碼水平如何?
有網(wǎng)友這樣回復(fù)：
劉強(qiáng)東在一次講座上，稱自己在校大三的時(shí)候，也就是1995年左右，他給別人寫代碼，一個(gè)晚上就能賺5萬。
95年一個(gè)晚上5萬，那是什么概念。
至于劉強(qiáng)東編碼的水平究竟怎樣，是不是像上面網(wǎng)友形容的那樣，可以一個(gè)晚上賺5萬，我們無從而知。
但可以肯定的是，無論是馬化騰還是劉強(qiáng)東，所編寫的代碼應(yīng)該很規(guī)范。
不知你有沒有類似這樣的這樣的經(jīng)歷：
回頭看看自己一年前編寫的代碼，驚訝地發(fā)現(xiàn)，哇哈，如此不規(guī)范的代碼，是誰編寫的？確定是我寫的嗎？我能寫出這樣慘目忍睹的代碼？分分鐘鐘懷疑人生。
代碼規(guī)范的重要性我們都知道，但要真正做好，還需要我們?cè)趯?shí)踐中慢慢的累積，不斷修煉。
03
如果代碼沒有統(tǒng)一的規(guī)范，每個(gè)人都按照自己掌握理解的那一套，那么整個(gè)項(xiàng)目的代碼很可能就會(huì)出現(xiàn)風(fēng)格迥異。即使是分工明細(xì)，每個(gè)人負(fù)責(zé)一個(gè)模塊，等到要整合代碼的時(shí)候就尷尬了。
很多時(shí)候，并非程序的算法有多復(fù)雜，或是邏輯多么復(fù)雜，而是因?yàn)榇a不規(guī)范，越讀越費(fèi)勁，把精力都耗在這里了。
統(tǒng)一的代碼規(guī)范可使得代碼可讀性大大提高， 在團(tuán)隊(duì)的合作開發(fā)中是非常有益而且很有必要。
04
項(xiàng)目維護(hù)工作不僅讀懂源碼，而且還需要在原有源碼基礎(chǔ)上作出修改。如果沒有統(tǒng)一代碼規(guī)范，很可能會(huì)出現(xiàn)這種現(xiàn)象：
張三完成開發(fā)以后，李四進(jìn)行維護(hù)加一段代碼，過一段時(shí)間王五又加一段代碼。原本一個(gè)很普通的需求，經(jīng)歷了N次迭代和修改，已經(jīng)形成了巨大的功能。直到有一天，張三、李四、王五都辭職了，新來的員工看到那一大堆沒有統(tǒng)一規(guī)范的代碼。想死的心都有了。
隨著不斷迭代版的維護(hù)成本越來越高，從而形成惡性循環(huán)。程序背后的架構(gòu)設(shè)計(jì)或模式固然重要，但良好的命名也不容忽視。不規(guī)范的命名不僅讓我們對(duì)代碼難以理解，更糟糕的是，會(huì)誤導(dǎo)我們的思維，導(dǎo)致對(duì)代碼的理解有偏差。
相反，良好的命名規(guī)范，則可以讓我們的代碼更加容易讀懂，也能向讀者正確表達(dá)事物以及邏輯的本質(zhì)，閱讀命名規(guī)范的源碼理解沒有那么費(fèi)勁，會(huì)有一種享受的感覺。
有人喜歡對(duì)控件textview1，textview2，textview3、，textview4類似這樣的命名，甚至還對(duì)其添加注釋。
有人可能認(rèn)為注釋越多，其他人看到的就會(huì)越好。其實(shí)不然，注釋過多，或是一些冗余注釋，反而會(huì)影響源碼的可讀性。如果我們良好的命名規(guī)范，結(jié)合了需要和命名。它可以省去許多不必要的注釋。
對(duì)于方法命名，首字母一會(huì)兒大寫，一會(huì)兒小寫；一會(huì)兒全稱一會(huì)兒簡寫；一會(huì)兒駝峰命名法一會(huì)兒匈牙利命名法。
當(dāng)然，起一個(gè)好的名字不是件容易的事情。首先，既要有盡量多的提供變量信息，又要盡可能的保證名字短小精悍，還不能為了短小而隨意采用縮寫而導(dǎo)致閱讀障礙，另外還要盡量保證以后程序更新后名稱仍然能很好的描述其內(nèi)容。
在編寫代碼中，要盡可能的遵守一個(gè)良好的命名規(guī)范，并且不停地的調(diào)整學(xué)習(xí)命名，從而逐漸掌握起一個(gè)良好名字的能力。
05
知道了代碼規(guī)范的重要性，但有時(shí)候迫于項(xiàng)目趕進(jìn)度壓力，有的因?yàn)榉爆嵉囊?guī)范作出很多額外的工作，影響了項(xiàng)目開發(fā)進(jìn)度，而漸漸被忽略。
規(guī)范不是對(duì)開發(fā)的制約，而確實(shí)是有助于提高開發(fā)效率的，最大的受益人其實(shí)還是自己。
不知你有沒有類似這樣的經(jīng)歷：
很多的時(shí)候閱讀自己的代碼，需要花費(fèi)很多時(shí)間？
尤其是出現(xiàn)bug的時(shí)候需要逐行的debug？
自己編寫的代碼過了一段時(shí)間后再來看自己都亂了頭緒。回到前面說的疑問，這代碼是我自己寫的嗎？
我們應(yīng)該做的就是規(guī)范開發(fā)，減少自己出現(xiàn)的錯(cuò)誤。很多時(shí)候項(xiàng)目的壓力一部分也是由于前期開發(fā)中遺留的眾多的問題。
那些看似無用的東西要經(jīng)過我們慢慢地累積由量變達(dá)到質(zhì)變的時(shí)候，相信你能體會(huì)到其價(jià)值所在。
養(yǎng)成良好的代碼規(guī)范不是為了別人，也不是為了公司，而是為了提高自己的編程修養(yǎng)，提高自己認(rèn)識(shí)事物的能力。讓自己編寫的代碼可維護(hù)性更好、可重用性和可擴(kuò)展性更強(qiáng)。
接手別人項(xiàng)目時(shí)，最讓你最難以接受的是什么？沒注釋，代碼亂？代碼冗余？架構(gòu)拓展差？歡迎留言！
【END】
