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

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

　　1、大量應(yīng)用開源項(xiàng)目不利于項(xiàng)目維護(hù)

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

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

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

　　3、精簡(jiǎn)的代碼不等于效率高

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

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

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

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