路漫漫其修遠兮，吾將上下而求索

今年年初的時候關注到 TGONetworks 舉辦了場 TGONext 有趣的活動，該活動由台灣的高階主管聯合舉辦，針對技術領域的三大主題：技術創業、技術管理、技術架構進行經驗的傳承。

撇除技術領域來看的話，不管是工程師或是 PM 或是行銷人員總會面臨到，在茫茫職海中我該繼續專研專業領域，或是選擇管理職，抑或是想不開走上創業的不歸路。

任何一條路線皆無好壞，端看如何做選擇。本文梳理了筆者如何在三大領域中做選擇，以及這半年以來技術管理組的參與心得。

前陣子參與到 TGONext 技術架構組的第一次聚會，這次聚會基於高併發而延伸出了許多討論，但因時間的關係，有許多主題並未深入地聊到細節，希望藉由這篇文章能引起大家來思考架構的本質。

最近在申請Facebook APP 給用戶做OAuth 登入時一直出現以下錯誤：

無法載入網址: 這個網址的網域未包含在應用程式的網域中。若要載入這個網址，請在應用程式設定的「應用程式網域」欄位中新增應用程式的所有的網域及子網域。

這是因為透過OAuth 取得使用者資訊時需要指定 callback url。

Dependency Inversion Principle

Depend on abstractions not on concretions

所有物件的相依關係需要依賴於抽象類別，例如 contract、interface、abstraction，而非 concretion class。

白話點來解釋，我們可以想像有一個檯燈、電視以及音響，當我們要使用這些電器的時候需要提供電量給他們運作沒錯吧？

所以這些裝置會有一個插頭，提供我們插電使用

但現在想像一下，如果沒有這個插頭的話該怎辦？

我們只能把這些裝置直接拉線進牆壁通電，但這一點也不方便，所以我們有了插座，把插座接上裝置的插頭就能使用了，換句話說，當你設計這些裝置的時候，你不需要去在意他怎麼收到電的，這些裝置反而是依賴某些介面，讓裝置們能直接使用電力，這才是正確的設計流程。

DIP 原則內有兩大重點，分別是：

1. High level modules should not depend on low level modules.
2. Both modules should depend on abstractions.

Interface Segregation Principle

A client should not be forced to implement an interface that it doesn’t use.

對於所有待實作的類別，不該強迫實作它不需要的方法。

有沒有過一種經驗，在開發時為了方便架構類別間的相依關係，把相仿類別中的部分功能抽象成 interface，並讓類別實作該 interface 內所描述的 method，但是往往一不注意會將越來越多的 method 抽象至 interface，可是這些多出來的動作對於其他類別並沒有實作意義，為了讓程式能順利通過所以又實作了一個空動作，長久累積下來，類別中多了一大堆沒意義的 method。

而ISP 原則便是在解決這種狀況，降低 interface 的耦合度並且提高內聚力。

Liskov Substitution Principle

Derived classes must be substitutable for their base classes.

對於父類別或者interface 出現的地方，都可以透過子類別或者該interface 的實作來取代，而不能破壞原有的行為

舉個例子來說，我們假設有一個取得所有課程的類別，而取得課程的方式可以透過Database 或者FileSystem 取得，因此我們可以將類別規劃如下：

Open Closed Principle

Entities should be open for extension, but closed for midification.
軟體中的對象，例如Class、Module、Method，這些對於擴展是開放的，但是對於修改是封閉的

OCP 是我在軟體開發中最愛使用的一個原則

對工程師們來說，開發軟體最怕的不是寫程式，而是改程式。改A 壞B，修C 又壞回A 的情況比比皆是

程式間的耦合性過高，雖然有寫測試化程式，但誰也無法保證測試的覆蓋率可以測到所有情況

OCP 便是減少修改過程中的出錯率，以及增加測試妥善率的最佳方法

而OCP 的最高境界就是達到：

藉由增加程式來擴充功能，而並非修改程式

SOLID 原則 - Single Responsibility

SOLID 代表著物件導向中，五種不同的開發原則，分別是：

1. Single Responsibility Principle (單一職責原則)
2. Open Closed Principle (開放封閉原則)
3. Liskov Substitution Principle (里氏替換原則)
4. Interface Segregation Principle (介面隔離原則)
5. Dependency Inversion Principle (依賴反轉原則)

對我來說，在開發過程中嚴守這五種原則，比起去運用某些Design Pattern 來得重要許多，但並不是說Design Pattern 不重要。

而是Design Pattern 的實踐，有很大的部分就是讓你不違反 SOLID 原則。

Single Responsibility

A class should have one, and only one, reason to change.
一個class 應該只做一件事

降低類別對於其他事物的依賴程度，便是Single Responsibility 的核心準則。

本文撰寫時的Vue.js 版本為2.1.8

Vue.js 使用HTML-based 的模板語法，允許開發者將Dom 綁定至底層的Vue instance，在讓Vue.js 再透過其本身的機制渲染網頁

而Vue.js 數據綁定的方式有兩種，一種是修改data 屬性的方法，而另一種是實作 computed function ，先來介紹一下這兩種使用方法

1. using data property

   1 2 3 4 5 6 7

   let vm = new Vue({ data: { return 'message': 'hello'; } }); console.log(vm.message) // output: hello

2. Using computed function

   1 2 3 4 5 6 7 8 9

   let vm = new Vue({ computed: { message() { return 'hello'; } } }); console.log(vm.message); // output: hello

最近在學vue.js，順便記錄一下
v- 是vue.js 在操作 DOM 時的前綴符號，但對於某些會經常使用到的指令來說似乎特別繁瑣
因此vue.js 對 綁定事件 與 屬性 的操作簡化成以下的寫法