大話 Clean Swift - 觀念篇
Clean Swift 這個程式架構取自於知名技術作家 Uncle Bob 的其中一本著作 Clean Architecture，而他其中一本著作 Clean Code 也是紅遍軟體開發界。Clean Code 講述如何把程式寫好，而 Clean Architecture 則是講述如何把程式寫的容易測試和容易擴充及除錯。相信 Clean Swift 的原創人 Raymond Law 想必也是 Uncle Bob 的書粉吧！才以 Clean 來命名。
只要踏入程式開發一段時間，除了把程式基本語法弄熟，且能把需求功能完成後，就會開始遇到程式碼開始雜亂的問題，這時有些工程師會試圖去了解一些軟體工程相關技能知識，例如會去學習重構方法、學習設計模式、學習如何寫出好的程式架構。但其實前面講得這三種方式都是在講同一件事，只是用不同的面向來解釋。
重構 = 使用 Martin Fowler 所著作重構聖經裡提及的數十種方法進行程式改造。
設計模式 = 使用 Gang of Four 四人幫所歸納出來的二十三種設計模式進行程式所需情境應用。
程式架構 = 沒有特定發明人，都是有經驗的開發大神所以釋出的開發架構，其實每種架構差異性不是太大。
重構和設計模式並非是今天的主題，坊間有很多經典著作都可以參考。
Clean Swift 所屬的是程式開發架構，跟它類似的是VIPER，另外像 MVP、MVVM 也是開發界經常使用的程式開發架構。
很多開發者會憂心要選擇哪一種架構，但其實這沒有標準答案，就算是一般預設使用的 MVC 也並非不好。那什麼時候該選擇除了 MVC 以外的架構呢？簡單說就是專案大小而定，如果開發團隊定義這專案屬中大型專案，那則建議使用 MVC 之外架構性更好的程式架構。
今天要介紹的是 Clean Swift 觀念，所以不會看到任何程式碼。我認為觀念是初始學習一件事要先建立的，能理解其觀念能減少碰壁機會，日後也能舉一反三，以下是今天觀念篇的正文。
說到程式架構很多開發者其實多少會心理產生畏懼感，就如同設計模式，我相信很多開發者買了書，但還是只會使用其中幾種常用的設計模式，其他設計模式在去有效使用，光看程式碼範例也無法了解因由為何 (在此我推薦重構，由重構去推衍到一種設計模式)。尤其在程式技術書的教學有很多抽象的詞語，光要理解都是一門苦差事。
但其實程式架構早就已經出現在我們的周圍，為什麼我們會無法自然的去使用呢？原因在於這支程式是你自己在寫的。
當這支程式都是你自己在寫的時候，通常就會從頭到尾把程式一次寫完，然後讓功能能正常執行。所以要了解程式為何要拆解成各種架構要回到理解分工合作的概念。
生活充斥著很多分工合作的事，例如運動。
以上兩種運動都是很常見的運動，這兩種運動在正規比賽中都不是一個人就能完成比賽，而是要團隊分工合作。球隊中不管排隊還是籃球，每個角色位置的功用都是不一樣的，我想這點很好理解，如果每個角色都由一人來作，我想會相當累人，甚至無法進行下去。也就是這樣，所以在籃球場從邊線把球傳出來一般是後衛選擇，在籃下的是中鋒選手，唯獨把角色區分出來，讓每個角色專注在自己的任務上才能把功能發揮到最好。除了運動以外，我想還有非常多的例子都能看到架構分層的重要性，舉凡銀行、郵局、大賣場、學生班上股長等等不勝枚舉。
那 Clean Swift 也有這些團隊分工嗎？是的，只是現實上這裡的團隊指的是我們要完成的功能。但今天我們仍是擬人法的方式來理解這團隊分工是怎麼作的。接下來我們有請五位能幹的角色出場。
這五位分別擁有重大的使命，本來我們把一個功能交給一個人作，現在要分拆給這五位來做，我想這薪水成本會提高，但我相信是值得的。(是的，你沒看錯，使用分層的程式設架並不會讓程式執行效率提升，甚至是可能會減少執行效率的)
今天有一項任務要完成，這五人幫要怎麼進行作業呢？(以上直接以人名作比喻，請自行對應原始程式檔名，例如大衛是ViewController)
任務名稱：向NASA美國太空總署取得地球跟月球的距離後顯示在看板上。
Mission Start!
1. 一開始我們請艾瑪進行看板顯示地球跟月球距離畫面的排版，把顯示距離地方作好。
2. 大衛負責主控，他會跟翠絲發出請求，跟翠絲說何時要去跟NASA索取距離資訊。
3. 翠絲取得距離資訊後，把原始資料格式轉發給龍一。
4. 龍一發現翠絲送過來的資料只有單位純數位，沒有距離單位，他的工作是作資料格式化處理到看板上可以直接使用。
5. 龍一處理完後把資料送往主控的大衛，因為龍一不能直接跟艾瑪接觸，必需由大衛跟艾瑪接洽。
6. 大衛確認手上拿到經格式化好的資料後，把最終資料交給艾瑪顯示距離。
值得一提的是，此次任務沒有讓洛特出馬，因為這次任務比較單純沒有畫面跳轉要帶資料的需求，所以洛特在辦公司待命。
經過一連串的分工合作，團隊終於把月球跟地球的目前距離展示在看板上，因為經研究月球跟地球距離逐年越來越近，所以必需作好這個觀察才行。
藉由以上這個簡單的需求務任，我想大家都能在很短的時間完成它，甚至可能會想，這不就單純Call API就完事了嗎？是的，這個例子很單純，但一個中大型的專案也是由這些大大小小的需求積累而成的。若你目前想作的單純就這麼簡單，那就不需要使用到分層的程式架構來實作。
在剛剛的月球任務中，我們能知道翠絲她要負責跟NASA要取距離資訊。在一般的任務中，可能一次的請求要再分拆成多個小任務，例如翠絲除了要跟NASA取得資料，也要跟某天文台溝通，這時她一個人可能就忙了。所以在 Clean Swift 中有提到，可以讓 Interactor 別這麼忙，當翠絲太忙時，應該要給她一些人力！一般公司情況是否也是如此？所以在 Clean Swift 中，Interactor 可以在拆成多個 Worker 來工作，一個 Worker 就只作一件事。翠絲要作的，便是管理這些工作人員了。
Clean Swift 的每個程式的依賴關係就是如此，若能理解這個觀念，既使是 MVP 跟 MVVM 也是能很快的適應它。
最後則放上實際的程式架構流程圖，有機會下次見。
