當我們談編程細節，我們在談什麼
練功房裏有個同學說，他拿着Args這道題目給一位有十多年工作經驗的老程序員看，讓他估計需要做多久。這位老程序員看了以後說，兩星期吧。
（老程序員而且非常有責任心，說需求討論就要1~2天。）
我本來覺得極客學院的同學們給我吹噓的“10X效率提升”有點太過，一看這個，頓時覺得信心滿滿啊~說10X效率提升簡直是太客氣了啊~
所以我就想啊，我們練功房的同學把Args練到了27分鐘，把FizzBuzz練到了1分10秒，到底這巨大的效率提升是從什麼地方來的呢？
它不是因爲你學到了什麼知識點，不是因爲你開了什麼領悟。效率的提升都是從細節裏摳出來的，從反覆的刻意練習中練出來的。
練功房裏的DXD同學列了一個FizzBuzz的操作分解。他以3分鐘完成FizzBuzz第一部分需求爲目標，把這個編程任務拆解到了每一個動作的粒度。比如說，我們看看他怎麼拆解“創建測試類”這個動作：
有沒有被震驚到的感覺？我第一次看到他這篇文章的時候，是被震驚到的。再看看他怎麼寫第一個測試：
怎麼說呢，看了太多高舉高打的討論，看到這樣一個細節程度與科比的《Detail》堪相媲美的文章，我感覺很舒服，因爲這纔是真正有用的東西。（DXD同學也鏈接了科比的視頻。感興趣的話可以點文末“查看原文”。）
當然DXD同學對細節的思考、對每個細節可能的變化，還沒有像Kobe那樣分析深入。比如要複寫toString的時候，其實可以直接在FizzBuzz類裏寫“to”，然後IDEA就會提示你是否要複寫toString，按Tab鍵就行了。
但他這個文章的價值恰好就在這裏。他把每個細節都亮出來，就給了自己反覆練習提高速度的基準，並且給了別人提出反饋的機會。這恰好複合刻意練習理論的要點：
-
刻意練習必須是大量重複的；
-
刻意練習必須是針對自己暫時還不擅長的動作；
-
刻意練習必須獲得及時的反饋。
把每一天、每個小時、每一分、每一秒、每個動作該怎麼做的細節都亮出來，我們說“如何做一件事”的說法就有了可錯性，有了可錯性我們纔有可以改進的空間。這就是細節的意義。
大而化之高舉高打的漂亮話是怎麼說都不會錯的。這也就是爲什麼這些漂亮話毫無用處。