AppWorks School Batch #16 Front-End Class 學習筆記&心得（Week 18）

（本文所有內容禁止媒體引用）

在個人專案最終的演示（demo）之後，緊接而來的是程式碼重構（refactor），在不影響功能的情況下進行優化，維持程式碼的品質。

取自 AppWorks School 前端班課程大綱

個人專案演示（demo）與錄影

為期五個短衝的個人專案，終於迎來最關鍵的「演示（demo）」環節，我們要在全屆以及多數校務、導師的面前，秀出過去五個星期努力的成果，用三分鐘的時間，從使用者的角度，完整介紹自己的作品。

專案演示可說是整個培訓營中，重頭戲中的重頭戲，所有人都不免感到壓力頗大，甚至有每天都穿 T 恤出現的同學改穿襯衫出現，幸好 School 把我排為全屆第一位上場，測試設備時間最多、緊張時間最少，度過戰戰兢兢的三分鐘之後，就可以好好地在臺下觀摩其他同學的作品。

隔天緊接而來的是錄影環節，呈現出來的畫面像是主播在播報新聞，專業感十足。這些內容將會提供給合作廠商，可以說是給人建立對自己專案第一印象的重要工具，有點類似產品或服務的宣傳短片，除了專案本身的內容外，也很吃作者的表達能力。

錄影現場

週一主題短講：重構與自動化測試

隨著個人專案進入尾聲，核心功能與使用者介面都已經完整，接著就可以開始關注程式碼的「品質」。

或許對於使用者來說，程式碼品質是否良好並不影響體驗，但對於開發者與接手專案的人而言，如果維護起來要耗費極大成本、加上新功能越來越困難、更動程式碼越來越容易造成專案整個壞掉，不如直接自己寫新的程式碼還比較快，那既有的內容等於什麼也沒有留下，這種程式碼若用通俗一點的詞形容就是「糞扣（shit code）」，或者用比較文雅的方式會稱為「既有程式碼（legacy code）」。

要維持程式碼的品質，ㄧ般會做兩件事情：「重構（refactor）」與「測試（test）」。

重構（refactor）

重構指的是在不影響功能的情況下，讓程式碼更好閱讀、更好維護，例如若有一個函數在多個頁面中都會使用到，就可以將該函數放在獨立的檔案中，再讓每個頁面去取用該函數。

測試（test）

顧名思義就是去試跑程式，看實際執行起來會不會有問題，可再分為「手動化測試（manual testing）」與「自動化測試（automated testing）」。

1. 手動化測試：直接找真人當使用者，進行人工測試，其壞處在於耗費人力、時間，且不容易想到或測完所有待測項目，容易有漏網之魚。
2. 自動化測試：用程式碼去測試程式碼，又可再分為測試最小單元的「單元測試（unit test）、測試整合後的多個小單元之「整合測試（integration test）」，以及測試整個使用者流程的「端對端測試（end-to-end test）」。

寫測試是一門大學問，School 在第 19 屆起甚至新增了「自動化測試」課程，我們這些初學者不太可能在不到一週的時間內就為自己的個人專案寫測試，因此多半還是靠人工找錯、並針對可優化的地方進行重構。

最後短衝：重構

跟前五週比起來，這個短衝相對輕鬆，不需要每天報告自己的進度，只要找到可優化的地方進行改善即可。此時主要會針對下列幾點進行調整：

1. 移除不必要的 console.log、註解、套件等。
2. 使用開發者工具檢視時，不應出現錯誤訊息。
3. 檔案名稱、變數名稱大小寫應符合規則。
4. 不同類型檔案應以資料夾區分清楚。
5. .gitignore 檔案應包含 node_modules、build、.firebase 等。

跟先前專案不同的是，我們這次是在自己的雲端倉庫（repo）中不同分支間互發 PR，導師頂多協助檢視、用評論的方式給予回饋，且因為程式碼量龐大，並不會像 STYLiSH 或 Dive into topics 時期那樣細看、也不會幫我們合併，絕大部分還是要靠自己把關。

週五主題短講：物件導向程式設計（OOP）

「物件導向程式設計（object-oriented programming, OOP）」是一種程式設計方法，其核心理念為節點與節點間可透過訊息互相溝通、改變狀態。

但若參考多數介紹 OOP 的說明（包含 MDN），則會解釋 OOP 為將資料封裝在物件當中，我們操作的是被物件封裝的內部資料，而非資料本身。

OOP 基本概念

在 OOP 中，會先製造一個藍圖，稱為「類別（class）」，再依據此藍圖建立一個一個實例（instance），稱為「物件（object）」。

以生活化的例子為例，就像是在製造飛機時，都會有機身、機翼、尾翼、引擎等構造，但每種型號的飛機都會針對各自適合的情境進行細部設計，產生適合短程的 737、適合長程的 777、適合大載客量的 A380 等；飛機就是一種「類別」，而各種不同型號的飛機，就是基於飛機這個類別產生的「實例」。

在「類別」中，會先定義好「屬性（attributes / properties）」與「方法（methods / functions）」，所有從該類別產生的實例，都能夠獲得該屬性與方法，並針對自己的需求進行微調，在每個實例中進行的調整，都不會影響其他實例。

OOP 四大特性：抽象、封裝、繼承、多型

了解 OOP 是依照定義好的「類別」建立一個個「實例」後，可以接著來看他們的特性：

1. 抽象（abstraction）：在實例中套用屬性或方法時，並不會在意該屬性或方法在原本的類別中，是怎麼定義的。就好像我們在使用手機時，不會在意其底層運作原理，只要可以撥接電話、瀏覽訊息就好。
2. 封裝（encapsulation）：某一物件的內部結構只開放特定項目供其他物件操作，其他全部隱藏起來。就好像一家公司會公開營運狀況供投資人與股東參考、舉辦公關活動供媒體與大眾參與，但其關鍵技術、與合作單位的合約內容就是商業機密，只有公司內部有簽屬保密協議的人可以瀏覽、操作。
3. 繼承（inheritance）：以上層類別為基礎建立的下層類別，都可以獲得上層類別的屬性與方法，讓程式碼得以重複使用。就好像透過「車」這個類別建立的「特斯拉」實例，跟其他車一樣都有四顆輪子在路上跑、具備前進、後退、煞車等功能，再以此為基礎建立專屬自己的「靠電力產生動能」特性。
4. 多型（polymorphism）：相同名稱的方法，若傳入不同參數，則會跑出不同結果。例如同樣都是讓動物執行「叫」這個方法，傳入狗這個引數會走得到「汪」的結果的程式碼、傳入貓這個引數則會走得到「喵」的結果的程式碼，這些程式碼獲得的引數不同、輸出結果不同，但方法名稱一樣都是「叫」。

某些介紹 OOP 特性的文章會忽略「抽象」觀念，但我們也不需要特別關注 OOP 概念中每個項目的細節。根據「Untyped 對啊我是工程師」凱心琳的《學校老師沒教你 OOP 物件導向的秘密 Why is Java NOT an OOP Language? 【電腦說人話】(CC字幕)》影片，程式語言並沒有所謂「是不是 OOP 之別」，例如前端框架 React 可以有 class component、也有 functional component。對於 OOP ，我們只要知道這些東西在程式碼中是如何被實現、以及為何對專案的開發與維護有幫助就好，太過鑽牛角尖對於提升自己的能力並無太多幫助。

SOLID 原則

物件導向程式設計有五個基本原則，有助於讓程式碼變動時更為穩定、維護與容易擴充，而這五個原則的英文名稱開頭正好可以組成「SOLID」，聽起來真的可以讓程式碼很穩固。五個原則包含：

1. 單一職責原則（single responsibility principle, SRP）：一個模組只對一個角色負責，不同角色依賴的程式碼不應耦合，以免改動到對應一個角色的模組時，也一併影響到另一個角色，詳細可見此篇文章。
2. 開放封閉原則（open-closed principle, OCP）：對於擴展性要開放、但對於修改要封閉，也就是說，如果要加上新功能時，應該是寫上新的程式碼，而非修改舊有的程式碼，實現方式包含繼承／多型（inheritance / polymorphism）、裝飾者模式（decorator pattern）、策略模式（strategy pattern）等，詳細可見此篇文章。
3. 里氏替換原則（Liskov substitution principle, LSV）：設計下層型態時，應該要遵循上層型態定義的行為，且不應繼承不必要的東西，讓下層型態在確保程式正確性不受到影響的前提下，可以取代上層型態，詳細可見此篇文章。
4. 介面隔離原則（interface-segregation principle, ISP）：不應強迫用戶依賴他們未使用的方法，在透過介面（interface）分割後，每位用戶都只會從模組中取得自己會用到的部分，詳細可見此篇文章。
5. 依賴反轉原則（dependency inversion principle, DIP）：高層模組不應該依賴低層模組，而應都依賴抽象（abstract），讓低層模組有變化、甚至發生問題時，不會影響到應保持穩定的高層模組，詳細可見此篇文章。

SOLID 原則屬於設計模式（design pattern）的內容，對於我們這些初學者來說，頂多只能透過生活化舉例、圖像化的解說大致理解概念，但若真要透過程式碼理解其實現方式，未免有些強人所難，待我們具有比較充足的開發經驗之後再來接觸，將會更有餘裕。

KKday 企業參訪

個人專案階段以「KKday 酷遊天股份有限公司」參訪活動作為結尾，跟位在松山車站附近的 91APP 比起來，KKday 的地段相對不便，週邊的飲食選擇不多，大夥在一旁的宜家家居內湖店用餐。找個地方吃午餐聽起來沒什麼特別的，但我當下可是有回到北歐的感覺呀，在芬蘭超市吃自助餐的回憶瞬間湧現！

在宜家家居內湖店吃午餐

KKday 是知名旅遊電商，隨著疫情趨緩、邊境管制漸鬆，旅遊相關的品牌都有一種蓄勢待發的感覺。活動先以資料、前端、後端、手機應用程式技術人員分享為主，資料領域還是安排在網路上小有名氣的 Irene 主講，我個人追蹤她的粉絲專頁已久，看到本人出現在面前時，有種見到偶像的感覺。

KKday 企業參訪合照（取自 AppWorks School 領英貼文）

比較特別的是，他們還邀請了 AppWorks School 歷屆學長姊現身說法，與我們分享轉職歷程，會後我們與每位講者也都有不少的切磋時間，是收穫頗豐的一個下午。

小班切磋時間（取自 KKday 領英貼文）

而要說整趟參訪最難忘的點，莫過於後端講者提到的「寫測試是一種道德素養」，而且對於初階工程師會用「最嚴格的標準」審視 PR，聽到這句話，臺下可是一片汗顏，我們既沒有幫任何專案寫測試的經驗、也已經很久沒有被做代碼審查（code review）。STYLiSH 階段被導師瘋狂退 PR 的陰影未退，而且聽他這樣講，工作時主管檢視的強度可能更高，前方的道路真是充滿挑戰。

心得

為期 5+1 週的個人專案階段居然就這樣結束了！記得前三週的 STYLiSH 階段就已經頗為痛苦，歷經個人專案後，才發現當時好像也不是那麼累。

個人專案最痛苦的點在於「不知道還要弄到什麼程度」，過往 STYLiSH 還有每天排定的進度（雖然永遠都落後），每被導師合併一個 PR 就有完成一個小任務的感覺，現在則是「完成一功能就要持續往上加新功能」，永遠有破解不完的難關，在徬徨、崩潰、平復、滿足、掙扎循環中的感受更強了，但也是這樣的壓力驅使，我們才得以在每個不舒服的時刻逐漸進步。

週四下午，導師安排讓我們從「技術角度」切入進行的演示，這對我來說無疑是一場震撼教育，一樣是 5+1 週的時間、一樣剛進來時很多東西都不會，同學們卻可以生出超多我完全沒有想過的新功能，有水平滑動、即時監測在線人數、多人視訊、計時後自動跳轉、圖片編輯器等等，單從使用者角度進行的演示還無法呈現背後變的魔法，待他們一一解析應用的技術，才驚覺：原來這就是所謂「技術亮點」！再看著自己幾乎只有 CRUD 跟一點點額外小功能的專案，真的是幼稚園等級的水準，還有非常大的進步空間。

校長很坦白地跟我們說，今年景氣相對較差，找工作會比前面的屆數辛苦，若有追蹤科技或軟體業的新聞，也能看到近期美國科技巨頭紛紛裁員、減招或緩招，臺灣或許沒有大量解聘，但職缺較去年少卻是不爭的事實，唯有持續增強自己的能力、並建立夠廣的人脈網，才能讓自己持續有更多機會。

參考資料

1. 物件導向(Object Oriented Programming)概念
2. Object Oriented Programming — The Four Pillars of OOP
3. 學校老師沒教你 OOP 物件導向的秘密 Why is Java NOT an OOP Language? 【電腦說人話】(CC字幕)
4. 使人瘋狂的 SOLID 原則：目錄
5. 物件導向基本原則 SOLID (Ruby Sample)
6. 軟體工程師為什麼要學 Design Pattern? | 物件導向 | SOLID | 工程師 Nic
7. 物件導向程式設計 — SOLID 設計原則 : SRP、OCP、LSP、ISP、DIP | 程式 x 概念 | 程式設計的武功心法 【Gamma Ray 軟體工作室】