【熵增教育】少編碼多思考：代碼越多 問題越多——熵增學院

學習語言而不是框架

我喜歡PHP、Python和JavaScript，喜歡用他們作些東西。但我卻不是Symfony、Django、jQuery開發人員。

我認爲這有很大的區別。一我的頗有可能成爲一名jQuery程序員而非JavaScript，也有可能成爲Django程序員而不是Python。在實際應用中，的確存在許多有價值且很是實用的工具和框架，但若是我僅知道如何使用一個框架，我想表達的觀點是在工做上只使用合適的工具其實會給任務帶來一些限制，你能夠查看一下，看看你用的工具，看看你用的框架。以個人經驗來看，一些複雜的全棧（full-stack）框架並非很是合適的工具，尤爲在靈活性和性能方面都不是太好。

集中精力學習一門語言會讓程序員變的更加靈活。全棧式複雜框架能夠幫助我快速的構建某個產品，但當我須要一個不屬於框架範圍內的解決方案時，它反而會變成一種傷害。我常常會採用「plug和pray」方法進行開發，當我發現某個庫或插件能夠知足需求時，我就會把它們應用到產品裏。這樣可能會使應用程序快速推出，但在之後的道路上會留下不少障礙。

此外，學習全棧框架和學習新語言同樣複雜。它們一般都有複雜的體系結構和術語，而且有些部分並不適用於其餘框架和工具上。固然框架也有許多好處，但前提是你必需要懂這門語言，而後才能理解其真正的工做原理，因此我寧願花時間學習更多關於語言自己的東西，而且把所學的技能應用到其餘語言或者庫上。

構建小模塊

有些小型的單元代碼是很好很討程序員們喜歡的，由於越小越容易理解且很難把它弄的很糟，因此限制編寫冗長複雜的代碼是很是重要的。

因此有目的的構建一些小模塊——儘量的接近需求目標。它們應該是獨立的塊，單純地解決某方面問題，可是把它們結合起來時，就能夠解決許多大型的、複雜的問題。

像這些簡單的模塊代碼修復起bug來也會很是容易。由於這些單獨的塊通俗易懂，一看就會知道其用途。若是模塊是自我包含的，那麼測試起來會更加簡單。

代碼越少越好

套用Biggie Smalls的一句話：「代碼越多，問題也就越多」。

誰都喜歡管理少的代碼。估計你們都有過這樣的體會，當審查一個功能模塊的代碼時，若是代碼不少很亂，第一印象確定很差，相反，若是該模塊代碼簡潔明瞭，你會很是愉悅。更通俗點講就是代碼越多，管理起來也就越困難：搜索代碼庫的時間會變長、查看文件導航也須要較長的時間、跟蹤執行也會變的困難等。

你是否發現，代碼審查、還有你使用的工具，很大程度上都是用來減小代碼量的。那些龐大的庫和長代碼彷佛會溢出人們的大腦緩衝區。當我在追蹤一段較長的源碼或執行跳躍好幾個源文件的功能時，我會感到很苦惱。這就是爲何我會喜歡給語法進行着色的編輯器，而且保持一致的空格對我也很是有幫助。

除了喜歡管理較少的代碼外，我還支持開發者們儘可能簡化代碼。程序員要爲應用程序所使用的代碼，不只僅是本身編寫的部分負責——甚至是這些應用裏的每行代碼。這也就意味着要替這些應用裏出現的bug或者安全漏洞負責。

你會在程序中使用本身不理解的代碼嗎？這並不表示我從不使用他人的代碼——坦白說，世上有許多優秀的程序員，可是在應用他人代碼的時候，你必須理解代碼，由於應用程序裏的每行代碼都很重要。在編碼時千萬不要忘記思考，編寫最少代碼的背後應該是多思考，這樣就不會給本身帶來沒必要要的麻煩。

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

編寫容易理解的代碼，少編碼多思考，這樣完成一個功能就會很快，生產力就會獲得提升。

固然，我也但願代碼是可驗證的。而且我一直認爲簡單、模塊化的代碼是更容易被測試。

代碼應具有的另外一特徵就是可讀。代碼應簡潔明瞭，語義清楚。在編寫代碼時，我會思考其餘程序員在第一眼看到它的時候會花多長時間來理解。或者一兩個月後我本身能一目瞭然嗎？正如你們熟知的那句編程諺語：任何一個傻瓜都會寫出可以讓機器理解的代碼，只有好的程序員才能寫出人類能夠理解的代碼。當我試圖發現它們工做原理的時間越少，作的事情就會越多。

可是不多有人能堅持這些規則，若是我說是，那麼我確定是在撒謊。有時候我也會很懶惰，甚至因爲時間限制，我會編寫一些複雜的、難以理解的代碼或者使用沒有審查的庫來實現某個功能。想要在短時間內編寫簡單、清晰的代碼會很困難——它須要更多的紀律和不斷的技術評估。特別是那種對時間敏感的項目，實行起來將會更難。

可是，當你花時間和精力去作的時候，你會發現功夫不負有心人——不只僅對本身有幫助，還會給其餘團隊成員帶來不少益處。