第一次貢獻程式碼

數個月前立志要作個能貢獻程式碼的工程師，除了回饋之外，最主要還是練習技術。當時選了 mozilla 作為目標，選擇了最簡單的官網內容維護的 github 專案。沒想到才一開始就卡住了，自以為 hack 程式有一些經驗的我，完全看不出來程式碼是如何被貢獻、審核通過的。

在群組中發了文，只聽到「fork」這個關鍵字，但仍然搞不清楚它究竟是在作些什麼，因此決定先把 pro git 那本網路書先看一看，找找有沒有說明這部分流程的內容。

經過兩三個月斷斷續續的看，終於讓我試著抓回一個 issue ，修改後發出所謂的 pull request ，也在一次回饋修正後，被順利併回主幹，放上網路。在興奮自己也能夠對真實世界有所改變之餘，也驚訝這一連串的工作，就在一個下午的短短數小時內完成。

為了這幾個小時內，實際工作不到 30 分鐘的事情，花費了我幾個月的時間去學習。只能說，自身的能力還有許多地方得趕緊加強，不然很容易一下子就被這個世界洮汰了。

用 Sublime 建置當下正在編輯的文件

為了避免那些常常出現，還看不懂的 Node.js 語法干擾我學習前端技術。打算狠下心來花時間對 Node.js 作點深入的了解。首先要先在同樣也在學習中的 sublime 進行設定，可以在編輯器中以快速鍵的呼叫 Node.js 執行正在編輯中的檔案，來加快學習的進度。Sublime 既然被稱作強大的文字編輯器，那一定有相對應的功能吧！

開始研究

sublime 可以由選單 Tools > Build System > ... 的列表找到內建的幾種建置模式。可以手動選擇，或是讓它停在 Automatic 的選項上，由 sublime 自行判斷。當選好或被判斷出適用於特定種類建置方式時。 Tools > Build 選單的狀態會是「可點選」，藉由點選它或是以快速鍵 「Command + Shift + B」或 F7 執行建置的動作。

不過 Node.js 不在預設支援的建置模式中，所以需要自行定義，由 Tools > Build System > New Build System... 選項，會開啟一個新設定檔，讓使用者可以自行定義。

學習 Unit Test 之三

在開發程式中使用單元測試，「封裝」這個概念似乎和單元測試相衝突。

封裝的原則是把程式邏輯隱藏，只保留必要的屬性、方法對外公開。這個基於保護的原則在單元測試中需要「觀察改變」的需要相互衝突。單元測試為了測出邏輯是否正確，就必須有對應的類別方法能夠觀察、確認數值的變化是否符合預期。將方法 public 變得無可避免。

在滿足單元測試需要的公開方法之後，希望達到「封裝」的目的，不要曝露出過多實作細節。就需要有個「過濾」的機制，這個時候「介面(interface)」就可以派上用場。其它程式只知道介面定義的方法，而不知道實作的類別額外公開的方法，原來為了單元測試的需要所開放的程式碼，就被介面所隱藏，以此達到保護邏輯的目的。

回過頭來看看之前所學，難怪看到的程式原則中，總是寫著「對介面撰碼」而不是「對父類別撰碼」。而程式碼中的註解文件(xDoc, 如 JavaDoc)中，也具有能將方法標注為「隱藏」的語法。看起來可能都是由於單元測試的發展而演化而來的吧！