感覺所有說不好理解的都有點賣萌的意思…個人覺得除了數(shù)學代碼需要分析成公式才能理解之外，其他的邏輯代碼都應該能看懂什么意思，只是有時候會不知道為什么要這樣做。

　　那么代碼太短的問題在哪里?

　　1、大量應用開源項目不利于項目維護

　　當然如果你的所有開源項目都是非常高質(zhì)量的代碼這個問題不大。但是萬一這些組件內(nèi)有一些不明顯的bug呢?或者互相之間存在某些沖突?又或者其中某些的依賴項沖突?再或者原來用著好好的，發(fā)現(xiàn)bug需要升級，升級后和其他組件不兼容了?所有這些問題都是實際應用中會出現(xiàn)的麻煩。

　　2、單純應用成熟技術(shù)不能提高自身的技術(shù)水平

　　同樣是從本地文件中搜索一個特定行，如果用了sqlite就只要寫一個查詢，如果自己去實現(xiàn)就要忙著操作文件、匹配字符串，如果文件規(guī)模大還要去學習文件系統(tǒng)接口的一些細節(jié)。如果你這些都熟練當然無所謂sqlite，但是如果你并不熟悉這些呢?類似的還有各種線程操作、界面響應等，雖然都是老套的東西，但是一旦深入一些細節(jié)就會接觸到計算機原理上的東西，很有意思也很有用。

　　3、精簡的代碼不等于效率高

　　很多語法糖都有這樣的問題，看似復雜的事情一句話解決了，但是這一句話意味著性能下降了數(shù)百倍。如果從來未曾寫過復雜版本的代碼，很可能不會意識到精簡代碼的性能存在問題，那么當遇到性能關鍵的需求時很可能無從下手。

　　4、優(yōu)雅的代碼不等于可讀

　　典型例子就如同java中大括號的用法之爭。如果if的執(zhí)行語句只有一行，需要用大括號嗎?性能上說用不用都一樣，好看上說有的人會覺得不用好看一些，也少按一次鍵盤。但是，如果你的代碼有幾萬行，需要從中找到這一句代碼，有大括號總會顯得更明顯一點。類似的還有其他知友用的單行代碼的例子。寫的時候爽了，過幾個月幾年再來看，讀都讀不通。

　　所以，總結(jié)來說——如果你的基本技術(shù)不夠精湛，快速生產(chǎn)可運行模版不是最關鍵的需求，不建議大量用開源工具和寫精簡代碼。當然反之如果已經(jīng)是技術(shù)大牛，且讀代碼能力極好，那么只要寫出來只有機器和自己能懂的代碼也不是個大問題。