改網站版型

發覺原來的網站版型真的不好閱讀，決定最新找幾個合適樣式先套用。之後再找時間把舊文章裡的程式碼樣式調成回來。反正最近的文章應該不會太多和程式碼相關，就先這樣囉～～

專案開發自勉

作為一個程式人員，總想著能利用程式來作些自己覺得有趣的事情。作個能 Open Source 的專案，在心中已經萌芽一段時間，卻一直未能正真進入開發階段。到咖啡館看書的時候，剛好聽到鄰座的教授和學生討論專題，心有所感。綜合之前看過的一些文章，將當下心得記錄下來。
相信工具 讓事情開始進行

相信工具 讓事情開始進行

隨著接觸過的專案越多，考慮的點也跟著的變多。開始的時候滿足於自己能夠「顧全大局」的成就感，但是也漸漸發現自己撰寫程式的速度不如以往。雖然寫出來的程式品質有跟著提高，但也隨著專案進行，發現許多當時考量的東西，最後不是沒有用到，就是需求改變而不敷使用，時間在無形中被浪費掉。倒不如早早開始動工，相信以依照現在的方法和工具，都有機會能夠將偏離的方向導回，沒考量到的部分予以補齊。

當然光是「相信工具」是遠遠不夠的，還要去學，去實踐那些工具和原則。像是不斷確認開發是朝著目標走，以此定義單元測試，並在發展的過程中反覆進行程式碼的重構。否則，只是單純的盲目前進，以及天真的期望哪天醒來，所有的問題會自然消失。

真正了解工具的背後意義，相信它們能夠幫助修正問題，然後就開始實作吧！不斷讓這些工具加入，讓事情發生！

解決問題 遠比用新技術更重要

無論一台機器功能再多，性能再好，如果不能用來打電話就算不上是一台手機。當為了追求的新的技術、新的管理方法、新的設計流程，一旦遺忘了根本的初衷，那麼產出的只一個堆積許多功能的四不像。一個連自己都不知道有什麼價值的東西，當然難以得到其它人的認同。所以產品的定位，想要解決的問題以及讓使用的人得到什麼價值，遠比用哪一種技術重要得多。

不管是 Scurm 專案發展、UML 圖或是 Big Data 、RWD ⋯⋯等等技術，都是為了解決在產品開發上，會遇到的一些問題。但也大多止於「產品開發」上，而不是「滿足客戶需求」或是「創造價值」。雖然學習各種新技術，能夠減少一些時間的無謂浪費，增加一些新的可能。但絕對不應該將所有的焦點都放在「新技術」這個議題上。選擇、引用，甚至是學習新技術，顯然比研究客戶問題、提出解決方案要簡單、不費腦力。看過一些人沉浸在新技術的堆疊，近乎在逃避解決客戶問題的責任。必須引及為戒，不能陷到這種狀況中。

片段時間 就開始 重要的是方向定下來

「我有想法，但沒有時間，找不到適合開始的時間點。」這個問題困擾了我許久，總是在一個念頭的開始，伴隨著公司加班，或是親友或自己的事情干擾，導致最終念頭仍然只是一個念頭，還是沒有被實現。因為如此，我的在職碩士，花了我整整五年的時間才完成，回頭來看還滿有趣的。前兩年我順利的完成所有的該上的課，沒有一科被當或出現危機。然而一個碩士論文卻花了我三年，而實際用在製作我的畢業論文的時間，大概才半年，那忙亂的半年中產出了一篇足以讓我畢業的碩士論文。而那半年之中，還有公司的專案趕工、上線等壓力在，常常強迫自己早點睡，六點起來寫一點文字，最後組成整篇論文。

事實上，我在完成論文的那個時段並沒有比較輕閒，所有的文字都是在片斷時間中撰寫，最後一兩週才抽出比較完整一些的時間去順槁。因此由小看大，表示別等著完整的時間才開始想作的事，既使只是片斷的工作成果，也能夠積少成多讓自己離目標更近一些。有一個明確，短時間不會被改變、大幅調整的目標，就可以開始動工了。大原則不變，其它的東西一面作一面微調方向就可以了。讓事情發生！比大量的規劃卻零產出有意義得多。

需求優先 別卡在細節

一個功能能夠有多少種變化？使用者操作上會不會看不懂？需不需要防呆機制？網站的安全性夠不夠？效能能不能讓主機承受上萬人同時操作？雖然這些問題對於一個成熟產品來說是必要的，需要常常去檢視，研究尋找更有好的解決方案。不過對於一個剛開始的計劃而言，這些都太遠了，不值得讓它們佔用本來就不太夠用的腦袋空間。人們可以忍受要等上一兩秒才算出報表的統計程式，但不能接受一個全世界最快，但只能算加法減法的計算機。

專案的目的是什麼？最核心想達成的功能為何？什麼是達到功能的最小可檢視流程？這些才是最需要常常問自己的問題。不斷的探索使用者遇到的問題，嘗試想出各種滿足需求的可能，去驗證它，分享它，再回頭去看看和大方向是不是一致。等到組合成一個夠完整的解決方案，再回頭去思考其它和需求比較沒有關連的問題或是優化產品的效能。

如果擔心一開始的程式規劃無法面對未來的變化，那就要在每一次的開發流程中，導入重構的技術。去相信重構的技術能幫助我們重新設計程式規劃，然後，開始進行吧！

第一個版本在哪裡？prototype？

產品終究是要給自己以外的人使用，所以，可展示的版本，或稱之為產品的原型，是發展的里程碑。最終目標太遠，往往會讓人失去想要達成的動力。最好能夠早一點作出能夠給別人看的原型產品，一來目標較近，有機會能在燒完全部熱情前完成，二來可以聽聽其它人對於這個東西的看法，能夠早一點作出修改，或是增強部分功能的力度。總之，都要比自己閉門造車完成後，才發現不合交通法規上不了路的好。

也許現在的想法有一些未盡理想之處，不過就像前面所說的，總是要先起了個頭，才能知道要如何改進，才知道對的方向在哪裡。

MVC 框架 － 容器與內容物的分離

我會的程式語言種類並不是很多，對於 MVC 框架的了解也是最近研究測試與重構後，才有了更深的了解，發現有一些自己與別人對於它的誤解，在這裡作作記錄和分享⋯

Context 物件

記得是在學習 Andoird 程式的時候，第一次接解觸到「Context」這的單字，在一些書本不是翻作「上下文」或是省略不提。花了許多時間嘗試理解，最後終於在字典外的一個討論串手有了一些些的了解。如果要我翻譯它的話，我會翻作「關連」。

在 MVC 框架中，會有一個作為組合所有元素的「容器」，在命名時常會使用「Context」這個單字，它的作用就是讓本來沒有交集的元素，相互之間能夠互動，讓值物件能夠被注入到的需要的物件中，讓發出的事件能夠被偵聽的物件收到。維繫這些元素之間互動關係，就是「Context」的責任，所以我認為翻成「關連」會比較好。

在 MVC 的概念中，每個元素都是獨立的，不知道會知道其它元素存在。因此可以更彈性地抽換、組合來滿足需求。而在這些元素之外，需要有個「容器」來裝它們，由於容器的程式實作通常已經被框架的開發者作完了，通常只需要繼承並覆寫需要改變方法，或是 new 出物件後，指定需要包含的類別有哪些，它們之間的關連就會被建立好。

在 Java 裡的 spring 框架，甚至只需要在設定檔指定套件的範圍，就能夠直接作「掃描檔案，判斷類別是否為 spring 元件」的工作，增加新元素變得更容易，也不容易漏了什麼關連。雖然這並不是 spring 框架的特有的能力，不過是我在其它程式語言的 MVC 框架中沒看到的特色。

[Robotlegs] Actor 找不到 IEventDispatcher 的依賴注入

今天嘗試將 FlexUnit (1.5)和 Robotlegs 兩個 framework 結合在一起，作為重構程式碼之用。開始還算順利，當我把假類別置換成整理過的實際類別時，測試回報「找不到 IEventDispatch 的 Inject 資訊(如下)」，造成無法開始撰寫第一個測試案例。

Error: Injector is missing a rule to handle injection into property "eventDispatcher" of object "[object TestingLogic]". Target dependency: "flash.events::IEventDispatcher", named ""

在程式碼中查了半天，就是沒有看到有任何需要 Inject 這個類型的資料。因為  Actor 是 Robotlegs 的既有類別，理論上應該不會出現缺少需要的 Inject 物件才是。所以中間一度懷疑是不是之前的同事去手動調整了的 Robotlegs 的核心程式。花了一點功夫，把 swc 解壓縮來看看，也看不出來有什麼異常⋯ (中間還查到另一段無關這次錯誤的歷史程式)

最後把焦點拉回到 Robotlegs 本身，因為 Context 本身具有發事件的能力，因此作為其 Model 元素的 Actor ，應該也是利用和 Context 一樣的物件來發事件，否則 Context 就得偵聽一大堆 EventDispatcher 所發出的事件。所以缺少 IEventDispatcher ，應該和 Context 有關，其中最可能的，就是在初始化的時候所帶入的 DisplayObjectContainer，這個類別有實作 IEventDispatcher 介面。

最後在這個地方的參數加上 new MovieClip()，就解決了這次的問題。也發現到原來在 Robotlegs 的事件發送，是依靠建構時傳入的元件，而不是由自己實作 IEventDispatcher 介面。不知道這個機制在 2.x  的版本有的改變，有機會再去試試看。

作個筆記⋯

學習 Unit Test 之一

為了重構一個專案既有程式碼，開始了重構的學習歷程，這些文章會把一些學習與實作中的心得記錄下來。剛開始深入研究的自己，也估不出來會用上多少篇文章來記錄，就估且用數字來的編號，等到未來遇到更好的文章命名方式，再回頭調整吧！

開始的篇章想先記錄的，是花了一兩個星期看完 Apache FlexUnit 指引之後的感想。作為一個成名已有兩三年以上的技術，在學習上並沒有我想像中的那麼容易，一些套件的名稱有了改變，原有的範例程式不能執行，或是舊版的函數庫已經找不到，得所有函數庫都升級到最新的版本。作為一個已經一段時間新東西可討論的技術，往往看到的都是數年之前的文件，當遇到問題，無人可問的無助感在心頭揮之不去。

所謂的「單元測試」，就如同其名一般只針對「單元」進行測試，所以雖然它也能夠發展成為某些「功能測試」的工具，但並不是它的設計初衷。從前的我一直認為「單元」只是表示它的測試「能夠細到每一個小單元」，並且對於每一項測試並不保證順序，以及每一次的測試都需要重頭執行測試項目初始化感到不解，認為它會造成在測試上的一些不確定性。

越是學習，越是覺得自己渺小

又換了一次工作，新的環境有比較多的時間，讓我能夠好好地對一些技術作深入研究。這在之前的工作中，還沒有發生過。往往是連續的專案進度壓力，或者是不斷需求方向改變。技術的理解往往停留在「能用」但是「不精熟」。

工作上需要用到 Flash，所以就把數年前想學習的 FlexUnit 拿出來學習，花了大約一週的時間看完放在 Apache 官網上的教學文章，總算是建立了一個能夠自動化測試 Flash 程式的環境，不過在回過頭要來修修手上的程式時，卻發現困難重重，不知要如何下手。因此又開始研究起所謂的「程式重構」是怎麼一回事。

重構是讓程式變得「乾淨」的步驟之一，而測試則是確保重構的過程中，仍然維持程式應有的功能。在看相關的資料的同時，發現了許多從前遇到問題的解法，程式架構與設計原則也在重構的重新詮釋下有了新的風貌。收起了自以為已經了解程式的自滿之心，同時也開始漸漸不能接受自己原來寫的程式，就像資料中提到的，我的程式已經長到一個難以擴充功能，也難以讓其它人理解的狀態，而天真的我還認為這是程式應有的風貌。

當然，就我那個時候的程式水平，會有那樣的想法並不意外。學習過程中，想法的被推翻與在連續的錯誤當中試著爬起，都讓人多多少少感到鬱悶，但在回頭看看自己的成長，已經有很大的進步，還是滿讓人興奮。終於能夠再接近高等程式應用一些，達到心中理想的境界。

興奮之餘，也發現到自己的渺小，能力的不足，在這個年紀才這樣的水平實在是不夠。既然現在有了時間可以研究技術，就得好好的把它們都補回來。充實自己的技術，才能發揮出更高階的價值，有資格的得到更多的薪水。畢竟，年紀不小，也到了支出要開始直線上升的時期了，得快快把自己準備好。

希望囉～在這系列的研究工作之餘，也能夠把所學多分享出來。也算完成多年前就希望作到的事情。