Ladies and gentlemen！Let’s welcome 小笠宏樹！！！
今天要來討論的是function
不過首先我打算開始一個新的習慣
每日一曲伴讀曲
4 Non Blondes - What's Up

先前情提要一下，我們在前一章有提到我們的假設是部門，而function就會是部門內部的運作邏輯還有對外的溝通邏輯。
以下我們會從軟體工程的角度去反推管理上常見的問題與困難。

function -> 部門管理

命名

通常對於public function的命名會以動詞為主，這其實很廢話，對於外部來說這個funciton是用來做溝通的，不是動詞是什麼。

變數不要超過3個

這也蠻好理解的，讓我們換個場景，通常我們去政府部門辦事情遇到最直接的麻煩是什麼，通常都是我們需要帶上各式各樣的準備資料，格式還要全對，然後我們就會很常在那邊來回奔波準備資料，所以麻煩需求變數少點好嗎？

不要暴露太多細節

我們最期待的叫部門做事的過程是什麼？當然是我把所需的資料塞給某個部門後，部門可能會先回應個什麼時候會做好，之後再直接將我要的東西寄信給我或送上報告來給我就好。
但....人生總是沒那麼簡單，相信各位都遇過類似以下的故事，「某日你拿著厚厚一疊的文件一下子跑到人資蓋章，一下子又跑到財務部門簽名，然後是上司簽名，總務簽名，再回人資確認，最後再把資料送回主管手上，而且中間你可能還因為流程不清楚，在資料的填寫或是流程上送錯了好幾次，然後一天就過去了」。
這就叫做過度暴露細節，明明當在第一個窗口時有確認完文件的齊備就直接幫忙往下送就好，對於當事人來說他是最不懂這些內部細節的人，也是最不需要這些細節的人，這就會導致有許許多多的時間浪費在傳遞細節上。

PS : 雖然這樣說，但也不是說公司治理的都是笨蛋，關于這種狀況的原因有以下幾種猜測

1. 公司不夠重視這些需要處理公務的部門，因此這些人員都需要非常多工，根本沒時間幫你做傳遞的動作。
2. 這個流程十分簡單，任何人都可以上手（這其實說的沒錯，但必須是一直有在接觸的人啊！）。
3. 這些時間成本的犧牲，跟建置解決方法比起來比較不花時間跟金錢（ERP系統可是很貴的）。

單個function盡量不要過大

當一個部門再接到一個任務後沒有嘗試的將任務分工，並交給主要負責人分別處理，那大家就會很混亂的擠在一起處理任務，然後時間互相卡來卡去，並且只有當任務被切開了後才會發現某些固定的pattern或是常用需要產出的東西，這時候才有辦法做出自動化的改善，以程式的角度就是將function拆小才比較容易將固定的邏輯提取出來，看要成立新的function或是新的Class來負責處理這件事。當然也不是拆得越細越好，拆的太多也可能會造成大家眼花撩亂完全不知道要怎麼分工。

單一功能原則

這個也蠻好理解的，通常我們會希望分配工作下去，這個工作被分工出來的任務是比較精確的，而不是包含著比較模糊的任務，因此才會出現這個原則，當然以軟體來說就會有如果有任何if else，那就應該拆成兩個function之類的都市傳說要求。

OK！又是一個完美的一天被我混過去了～
以上就是今天我帶著大家去思考部門與function之間關係的內容。
明天我會來批評一下上司XD，好啦～沒有啦～是來解釋為什麼上司說的話都這麼的模糊難懂！