歡迎光臨「軟體理髮廳」理髮廳，我是您的理髮師 小笠宏樹，想問顧客您今天想要怎樣的髮型呢？要不要試試看我們最新的Rx髮型或是歷久不衰的OOP髮型？

週末我們來點異國風
The HU - Yuve Yuve Yu

嗨嗨～大家好～
今天我們要來聊的是公司裡面的外包行為
其實外包行為我們在軟體裡面也非常常見，沒錯，就是import別人的library
也因此我們也時常看到公司外包時會出現的狀況，也出現在軟體import別人的library時，以下我們分成外包行為時外包對象與公司裡面分別來討論

外包對象

首先當然就是要讓外包是越簡單使用越好，不然怎麼快速賺錢，而在程式上我們是怎麼做到的呢？

• 工廠模式
  • 非常剛好的，我們在使用library時，時常會用到工廠模式，而這個是有原因的，因為外包的對象通常是工廠為了簡化外包時外部使用起來的複雜性，這時候就可以利用工廠模式就會像是點飲料（大奶薇薇、小綠微微、中伯爵紅少正常）的方式流水線生產出對方需要的物品。這種方法在另一個方面也是為了隱藏細節，以剛剛飲料的例子，其實光以容量來說就可以分成各式各樣的容量，但為了簡化顧客在使用這個外包飲料的服務，飲料店就會先訂出我們只有大中小這幾種可供做選擇，以免顧客選了奇怪的容量後，還需要詳細定義到底飲料的調配比例是否要跟著更動等等的細節。
• 單一溝通介面
  • 在Library裡面也會很常看到有一個主要的溝通對象，像是以XXXManager命名的主要溝通對象，在外包公司裡面也是，通常會有一個溝通的部門當做與其他公司溝通的管道，這個部門就會限制了外部如何去使用Library的功能，來舉個反例好了，假如使用者剛好有用過firebase android的library，就會發現在之前的時候，firebase會是將很多的功能都放在同一個library裡面，這導致使用上會比較難上手，需要一直去官網查詢要如何使用某一個特定的功能，因為每一個功能都會有他各自的Manager，而後Google也開始想慢慢的的將其拆開成不同的library，一方面是避免使用者明明只需要部分的功能卻需要將全部的功能都放進專案裡，另一方面也是讓使用者好上手，想用什麼就學什麼就好。

公司內部

對公司來講，外包終就是外包，而要發揮外包最大的好處就是有便宜的就要換，因此對於公司來講對外包的依賴度程度越低是越好的，那接下來就來討論一下如何降低依賴程度吧～

• 介面層
  • 最不該做的事就是，每個部門都自己去跟外包廠商溝通要什麼，各位客官可以用程式的方法想想看，以這個例子如果換了個library，大家就一起改到死。因此通常來講，我們會嘗試的建立一個卡在library與其他程式之間的介面層，這樣假如換了library也可以只改這個介面層裡面的邏輯，這對於公司來講也是一樣的，我們很常看到有某個部門專門處理外包的問題，而其他的部門如果有外包需求都是透過這個部門去處理。
• 不要當奧客
  • 有一種麻煩的情況就是明明就決定外包了，卻還是非常不滿意外包帶來的限制，一直想將自身公司的邏輯也加入到外包的流程中，這就像是明明飲料店就只有大中小的杯子，你卻說你要250ml，如果只有一個兩個客製化還好，但如果太多了之後，即便你有上面提到的介面層，也會導致這個介面層與各個部門出現相依性，最後導致這個介面層很容易因為外部的一點變動而導致需要跟著一起變動，甚至是換了一個library後，以前的邏輯就必須全部丟棄重來。結論就是假如你要外包就要知道外包是有其限制的，不是越讓其客製化越好。

好哩～以上是關於外包的印證
接下來的週一會來講外包的下一個階段併購