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

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

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

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

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

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

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

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

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

構(gòu)建小模塊

有些小型的單元代碼是很好很討程序員們喜歡的，因為越小越容易理解且很難把它弄的很糟，所以限制編寫冗長復(fù)雜的代碼是非常重要的。

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

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

代碼越少越好

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

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

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

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

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

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

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

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

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

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

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

。