南寧達(dá)內(nèi)：少編碼多思考,代碼越多問題越多

大約一年前，我曾編寫過一些PHPWeb編程守則——MicroPHPManifesto。但我發(fā)現(xiàn)各個(gè)語言之間有一些共同的編程/編碼規(guī)則，這或許是我在熟悉各種類型的編程語言后的一些收獲吧。下面是我總結(jié)出來的一些規(guī)則，并且...

大約一年前，我曾編寫過一些PHPWeb編程守則——MicroPHPManifesto。但我發(fā)現(xiàn)各個(gè)語言之間有一些共同的編程/編碼規(guī)則，這或許是我在熟悉各種類型的編程語言后的一些收獲吧。

下面是我總結(jié)出來的一些規(guī)則，并且在實(shí)際中應(yīng)該牢記于心。

學(xué)習(xí)語言而不是框架

我喜歡PHP、Python和，喜歡用他們做些東西。但我卻不是Symfony、Django、jQuery開發(fā)人員。

我認(rèn)為這有很大的區(qū)別。一個(gè)人很有可能成為一名jQuery程序員而非，也有可能成為Django程序員而不是Python。在實(shí)際應(yīng)用中，的確存在許多有價(jià)值且非常實(shí)用的工具和框架，但如果我僅知道如何使用一個(gè)框架，我想表達(dá)的觀點(diǎn)是在工作上只使用合適的工具其實(shí)會(huì)給任務(wù)帶來一些限制，你可以查看一下，看看你用的工具，看看你用的框架。以我的經(jīng)驗(yàn)來看，一些復(fù)雜的全棧（full-stack）框架并不是非常合適的工具，尤其在靈活性和性能方面都不是太好。

集中精力學(xué)習(xí)一門語言會(huì)讓程序員變的更加靈活。全棧式復(fù)雜框架可以幫助我快速的構(gòu)建某個(gè)產(chǎn)品，但當(dāng)我需要一個(gè)不屬于框架范圍內(nèi)的解決方案時(shí)，它反而會(huì)變成一種傷害。我經(jīng)常會(huì)采用“plug和pray”方法進(jìn)行開發(fā)，當(dāng)我發(fā)現(xiàn)某個(gè)庫或插件可以滿足需求時(shí)，我就會(huì)把它們應(yīng)用到產(chǎn)品里。這樣可能會(huì)使應(yīng)用程序快速推出，但在以后的道路上會(huì)留下很多障礙。

此外，學(xué)習(xí)全?？蚣芎蛯W(xué)習(xí)新語言一樣復(fù)雜。它們通常都有復(fù)雜的體系結(jié)構(gòu)和術(shù)語，并且有些部分并不適用于其他框架和工具上。當(dāng)然框架也有許多好處，但前提是你必須要懂這門語言，然后才能理解其真正的工作原理，所以我寧愿花時(shí)間學(xué)習(xí)更多關(guān)于語言本身的東西，并且把所學(xué)的技能應(yīng)用到其他語言或者庫上。

構(gòu)建小模塊

有些小型的單元代碼是很好很討程序員們喜歡的，因?yàn)樵叫≡饺菀桌斫馇液茈y把它弄的很糟，所以限制編寫冗長復(fù)雜的代碼是非常重要的。

所以有目的的構(gòu)建一些小模塊——盡可能的接近需求目標(biāo)。它們應(yīng)該是獨(dú)立的塊，單純地解決某方面問題，但是把它們結(jié)合起來時(shí)，就可以解決許多大型的、復(fù)雜的問題。

像這些簡單的模塊代碼修復(fù)起bug來也會(huì)非常容易。因?yàn)檫@些單獨(dú)的塊通俗易懂，一看就會(huì)知道其用途。如果模塊是自我包含的，那么測試起來會(huì)更加簡單。

代碼越少越好

套用BiggieSmalls的一句話：“代碼越多，問題也就越多”。

誰都喜歡管理少的代碼。估計(jì)大家都有過這樣的體會(huì)，當(dāng)審查一個(gè)功能模塊的代碼時(shí)，如果代碼很多很亂，第一印象肯定不好，相反，如果該模塊代碼簡潔明了，你會(huì)非常愉悅。更通俗點(diǎn)講就是代碼越多，管理起來也就越困難：搜索代碼庫的時(shí)間會(huì)變長、查看文件導(dǎo)航也需要較長的時(shí)間、跟蹤執(zhí)行也會(huì)變的困難等。

你是否發(fā)現(xiàn)，代碼審查、還有你使用的工具，很大程度上都是用來減少代碼量的。那些龐大的庫和長代碼似乎會(huì)溢出人們的大腦緩沖區(qū)。當(dāng)我在追蹤一段較長的源碼或執(zhí)行跳躍好幾個(gè)源文件的功能時(shí)，我會(huì)感到很苦惱。這就是為什么我會(huì)喜歡給語法進(jìn)行著色的編輯器，并且保持一致的空格對我也非常有幫助。

除了喜歡管理較少的代碼外，我還支持開發(fā)者們盡量簡化代碼。程序員要為應(yīng)用程序所使用的代碼，不僅僅是自己編寫的部分負(fù)責(zé)——甚至是這些應(yīng)用里的每行代碼。這也就意味著要替這些應(yīng)用里出現(xiàn)的bug或者安全漏洞負(fù)責(zé)。

你會(huì)在程序中使用自己不理解的代碼嗎？這并不表示我從不使用他人的代碼——坦白說，世上有許多優(yōu)秀的程序員，但是在應(yīng)用他人代碼的時(shí)候，你必須理解代碼，因?yàn)閼?yīng)用程序里的每行代碼都很重要。在編碼時(shí)千萬不要忘記思考，編寫最少代碼的背后應(yīng)該是多思考，這樣就不會(huì)給自己帶來不必要的麻煩。

編寫簡單、有用可讀的代碼

編寫容易理解的代碼，少編碼多思考，這樣完成一個(gè)功能就會(huì)很快，生產(chǎn)力就會(huì)得到提高。

當(dāng)然，我也希望代碼是可驗(yàn)證的。并且我一直認(rèn)為簡單、模塊化的代碼是更容易被測試。

代碼應(yīng)具備的另一特征就是可讀。代碼應(yīng)簡潔明了，語義清楚。在編寫代碼時(shí)，我會(huì)思考其他程序員在第一眼看到它的時(shí)候會(huì)花多長時(shí)間來理解?；蛘咭粌蓚€(gè)月后我自己能一目了然嗎？正如大家熟知的那句編程諺語：任何一個(gè)傻瓜都會(huì)寫出能夠讓機(jī)器理解的代碼，只有好的程序員才能寫出人類可以理解的代碼。當(dāng)我試圖發(fā)現(xiàn)它們工作原理的時(shí)間越少，做的事情就會(huì)越多。

但是很少有人能堅(jiān)持這些規(guī)則，如果我說是，那么我肯定是在撒謊。有時(shí)候我也會(huì)很懶惰，甚至由于時(shí)間限制，我會(huì)編寫一些復(fù)雜的、難以理解的代碼或者使用沒有審查的庫來實(shí)現(xiàn)某個(gè)功能。想要在短期內(nèi)編寫簡單、清晰的代碼會(huì)很困難——它需要更多的紀(jì)律和不斷的技術(shù)評估。特別是那種對時(shí)間敏感的項(xiàng)目，實(shí)行起來將會(huì)更難。

但是，當(dāng)你花時(shí)間和精力去做的時(shí)候，你會(huì)發(fā)現(xiàn)功夫不負(fù)有心人——不僅僅對自己有幫助，還會(huì)給其他團(tuán)隊(duì)成員帶來很多益處。

。