編程的知識體系

在關閉了我的博客http://www.fluidea.cn後，我又有了寫博客的衝動。這回就不打算再去折騰自建網站了，直接用別家的服務省事。

一個技術人員，學習一門新的技術時，必需要看文檔和教程。在網絡上，充斥着各類各樣的教程，微博也好，論壇也好，處處都是信息資源，但要找到一個優秀的教程並非件容易的事。要深刻掌握一門編程語言，或者一個技術點，必然要通過系統的學習，僅僅依靠看幾篇零散的技術文章，沒有可能構成本身的知識體系。

寫書的體驗讓我構建了系統的知識體系

在寫第一本書《Flex第一步》時，對"教程應該怎麼寫"這個問題並無什麼想法，只是下意識地憑藉着閱讀經驗和我的的工做經驗完成了這本教程。如今回過頭去看，以爲這本書的結構湊合，內容也還算合乎邏輯，但僅此而已。若是有用更高的標準去衡量，就會發現這本書很是淺薄，本身的東西不多，徹底是硬技術點的堆積，典型的短平快教程。

三年後，寫《AIR Android應用開發實戰》時，應該說對寫書有了更深刻的認識。在前期設計目錄、準備素材的過程當中，一直想着在書中怎麼體現更多的內容，特別是本身的開發體驗。安排內容時，考慮到AIR移動開發主要以遊戲爲主，所以有意識地添加了遊戲的元素，去除了新浪微博客戶端這類應用例子；另外，爲了讓書不那麼平庸，也嘗試加入了更多的知識點，擴充寬度。總的來講，這本書和個人最初的計劃差很少，我的比較滿意。

在書即將審稿結束時，Stage 3D開始支持AIR Android，這讓我一度非常糾結。若是要補上這塊，書店印刷時間又要日後拖，當時已經比計劃出版時間晚了幾個月。時下Flash業內寒流涌動，Adobe更是昏招頻出，讓我實在鼓不起勇氣繼續寫下去。也算是一個遺憾。

這兩本給我帶來了很大的收穫，不是經濟上的（收入少的可憐，特別是第二本），而是讓我創建了一套知識體系。明白一個問題和向其餘人講清楚這個問題，這實際上是兩回事。清楚地闡述一個問題的前提是理解這個問題的來龍去脈，爲何要這樣作？有沒有其餘方法？這個方法的優勢在哪裏？

寫書必須有嚴謹求實的態度，對一個技術點若是本身也是模棱兩可，就輕率地告訴讀者，這是不負責任的表現。

重構經驗，造成系統
像我這樣，從事編程快十年了（提及來慚愧，到如今一事無成），各類項目，各類技術都有接觸，但都是些很零散的知識點，沒有系統。知識的系統化很是重要，如何去系統化？那就是寫出來。寫的過程當中，天然會去思考，重溫，概括，總結，最後化繁爲簡，按部就班地倒出來。

通常咱們瞭解一個事物，習慣按照：是什麼-爲何用它-怎麼用，這條路去學習。但現實是，技術人員彷佛愈來愈浮躁了，老是想走捷徑，直接從「怎麼用」這步開始。其實這沒有很差，但通過一段時間後，必定要回頭把前面兩步走一遍。一件事物的本質，看似簡單，卻表明這它最根本的意義。若是咱們不清楚本身行爲的含義，又怎麼能把握前進的方向？