開發者與使用者角色並存的「設計」思考與思考「歷程」：ALPHA Camp全端網路開發第四學期課程心得(第五部分，全端：里程碑)
(註，第四學期的課程在2020上半年，即筆者修習此課程後有所調整，除名稱外至少作業和教材內容有所調整，如2020年版前端課程改為第三學期的全端/後端部分；
另外為方便稱呼，其實是想偷懶(X)，底下以”JS”作為”JavaScript”的簡稱，及”AC”作為”ALPHA Camp”的簡稱)
前情提要：ALPHA Camp全端網路開發課程個人系列心得(2019年版課程)
半年多前，寫第一篇系列心得開始，我突發奇想的想用”5W1H”六何分析法來逐步回憶我轉職網路工程師的學習過程；半年過了，當初設定的目的已一一達標，只剩未來求職成功預計時程(when)，與現正在寫的個人(who)收尾心得二篇，其中這篇也作為完成AC系列課程的里程碑，這之前先是時候快速瀏覽過去的經歷了(為方便讀者輕鬆補脈絡，也用搞笑與簡單的方式說明)：
1. 重新投入學習程式前的心路歷程：ALPHA Camp全端網路開發學期前課程心得(第一部分，背景：前傳？)
轉職動機的形成(打算砍掉重練)，像為何(why)會想不開(X)
2. 從「修改遊戲」找到寫程式的樂趣：ALPHA Camp全端網路開發第一學期課程心得(第二部分，基礎：暖身)
發現興趣的原因(有時像電玩有趣)，即如何(how)入坑(?)
3. 藉「學習鷹架」適應學程式的思維：ALPHA Camp全端網路開發第二學期課程心得(第三部分，前端：啟程)
確立方向的過程(從試探到固定)，是什麼(what)蒙蔽了我的雙眼(…)
4. 關聯「舊有經驗」以輔助學習的開發自「決」(學)：ALPHA Camp全端網路開發第三學期課程心得(第四部分，後端：核心)
決定領域的關鍵(比較想走後端)，如何處(where)是歸程(！)
帶完前面的心得後進入正題，我將以二部分的篇幅來談最後一個學期的學習心得：上半部分是「設計思考」，從學期開篇的產品設計概論開始，結合開發與使用者的觀點，以及課程中後期學習與專案開發的實際體悟，作為從課程畢業的總結性報告；下半部分則想聚焦在個人觀點，回顧自2019年初第一學期起的學習與思考歷程，與最後仿論文謝辭的形式名列致謝，為我在AC學習網路程式開發的時期，正式畫上階段性的句點。
為方便與下文參照，先附上這學期範圍內各部分的短篇心得連結：
1. 學期四期初：續上學期最後的關聯式資料庫課程，帶領餐廳論壇實作，並介紹產品設計、前後端分離、開發週期、自動化測試等概念
程式開發的設計思考
遵循AC課程的傳統(？)，最後一學期的開端也是較軟性的概念介紹，這次則是專案開發的前置作業：產品設計之設計思考(或稱設計思維，Design Thinking)。 設計思考可以理解為「以使用者為中心(user centeric)，思考產品設計如何解決問題(problem solving)的流程」，常區分為五個階段(個人簡單整體版)：同理(Empathize/Empathy，理解使用者需求想法)、定義(Define，聚焦具體的問題項目)、發想(Ideate，創意激盪出概念方案)、原型(Prototype，製作雛型來展示操作)、測試(Test，與使用者溝通和互動)。
實務上，工程師不太可能完整參與上述整個過程，那為何還要懂產品設計？ 以我目前的理解，其實大概知道其概念就好，但重點是要能將設計思考融入開發過程，讓開發出來的專案，能更貼近使用者中心與解決問題的產品初衷。 作為工程師，理想上不只是依規格寫代碼的「碼農」，而是能依需求做產品解決問題的「開發者」，如我從全端(包含介面設計與功能運作)角度開發期中與期末專案時的心得，剛好可以呼應到設計思考的五階段。
同理：至少要能接受自己產品的使用體驗，要能自圓其說
開發者其實同時也是最早的使用者，且因為有「球員兼裁判」的優勢，若能在接觸到「最早期產品」時，也帶入身為使用者「換位思考」的體驗角度，便能獲得第一手的修改建議，將陳品琢磨的更合人性，就算不能代表多數人的意見，至少做得出自己能接受的東西。
以我在開發期中twitter專案通訊功能的經驗為例，在寫出能即時傳遞訊息的功能後，便是要配置對應的操作介面。 我回想起以前使用不同通訊軟體二人私訊與多人群聊的經驗，將個人認為其中共通、基本且好用的要素寫進自己的專案，並透過反覆的測試去調整按鍵的形式、對話框的效果、操作前後的邏輯，甚至是在不同視窗大小的版面配置，花時間與心力打磨UX/UI後，終做出開發者自己感到滿意的成果(也獲得助教不錯的評分)。
簡言之，就是從實際使用的角度去「同理」，畢竟自己就是離開發者最近的使用者，不滿意可以直接反應與修改！
定義：建議先評估項目的可行性或複雜度，以免進度卡住
開發過程中，如果只依據訂好的規格項目依序動工，很有可能在不熟悉，或繁瑣的環節花太多時間，甚至一時做不出來，使進度塞車停滯。 相較之下，如果能在先期討論與開發當下大概推算這項功能要怎麼做、步驟的數量與時間，即先確認「是否有把握完成該項目」，沒有的話則視其必要性請求協助、跳過之後再做甚至直接省略，才能減少卡關或失敗的時間浪費。
這次改以我期末電商網站的例子，原本規劃要做出在所有頁面都能顯示目前項目的購物車互動視窗，我在動手前先想了一下可能的作法：前端使用Bootstrap的modal，並需要在加入商品到購物車後自動觸發顯示；後端需在各路由設定讀取購物車的資料才能顯示，或統一在app.js設定為環境變數。
然而，以上都只是初步概念，實際上這些方法我只聽過並沒實際寫成功過，以前簡單嘗試時無法正確顯示資料，看來得花很多時間去研究。 由於當時還不確定口試梯次，如果我被排到第一批，剩餘的時間恐怕來不及如預期全部完成，因此我決定先把其他有把握的基本部分做完，如果時間不夠，購物車就直接用教案的簡單單頁顯示，至少專案還算完整。 確定排在第二梯後，由於時間更充沛，我便能多次自行嘗試與向助教提問，經二週才將這項功能做到盡善盡美。 如果當初我執著於先把購物車做好做滿，搞不好其他項目就沒時間做完了！
發想：也許達成功能需求的方法不只一種，包含取消或替換
延續上面對開發項目的討論，考量點不只是先後順序的問題，更需要去想其本身的意義，除了思考怎麼如原先構想直接達成功能外，還可能是其實不需要去實做這個功能，或是用其他的替代方案達成即可，堅持以預期去做的話可能又花太多時間，做出不好用、很少用，甚或根本做不出的功能。
這裡也以我期末電商網站專案為例，多重選單是另一個複雜的功能，預期要能顯示商品三個層級的分類，但第二、三層的分類項目眾多(至少破百)，且選擇主分類時只能顯示所屬次分類，得仔細思考如何處理分類數量與關係。
初步構想與先做出第一層分類後，我發現實現二三層的難度遠比預期高，連如何求解的關鍵字也很難下(比購物車還棘手，作法更不確定)，只好改從該項功能「本質」思考其存在的意義(變哲學了……)：以展示小型專案的實際需求來看，由於模擬商品的假資料量小，完整的選單其實並不必要，甚至只有一層選單也不影響當前體驗。
結果我選了折衷方案，只用第一層選單的做法做出二三層，二三層因此沒有與上層分類的關係，只是填入隨機生成的資料當裝飾，並寫在程式碼註解，代表我有考慮過時做多層選單，只是礙於時間與技術先做示意的原型，未來有新的想法在補完或直接取消掉，算是用迂迴的方式重新定義與達成需求。
原型：其實可多參考模仿現成的產品，只要別無腦抄襲
除設計期提出的專案原型，「原型」的概念其實設計前與開發後也存在，畢竟創造時不可能完全憑空想像，必然受既有事物的形象影響。 開發者同時也是其他產品的使用者，本身也瀏覽過各種程式功能與介面設計，多少也能憑個人經驗評斷使用體驗的好壞，轉回開發時便有「見賢思齊焉，見不賢而內自省也」的感觸。 然而，若只是將他人作品好的部分照搬，這已非模仿而是抄襲，至少有一定程度理解與重新詮釋(是自己想過才寫的程式碼)，詮釋出「開闢、發崛」的創造性，才稱得上開發。
同樣以我的期末電商專案為例，雖當初設定目標是復刻citiesocial電商網站，做出「山寨版」的網站，避免花太多時間在產品設計而占用開發時間，也就是直接拿既有的成品當作設計階段的原型，學習其整體介面與功能的購物體驗設計。 然而，這次的專案目標只是模仿，而不是百分百做出一樣的產品，開發期間的任務是「如何用自己的方法做出類似的效果」，畢竟要像就直接照抄原本代碼，但那樣就沒有練習的意義了。
另一方面，也因為原型的網站規模龐大，且包含的功能特點眾多，有些複雜難度高，加上無法看到後台設計，有限時間與權限內不可能全部學完，只能挑選出滿足購物需求的主要功能來實作，有實物參考與看不到的部分則都得自己「腦補」。 腦補正是從模仿過渡到創造的重要階段，如我除了依據原始設計用Bootstrap重新刻出版型與JavaScript實現互動效果，沒有頁面可參考的後台管理與購物後訂單頁面，則是學習蝦皮購物的個人商店經營介面，並實際測試操作體驗後逐漸調整，讓專案多出開發者提升使用體驗的巧思。 簡單來說，若有特定的規格或對象作為原型模仿，仿作優點之餘再用自己的思考適度調整以創新，就能更明確的往解決問題的開發之路前進。
測試：透過開發過程中的反覆使用，察覺應當修改之處
測試的概念其實在開發過程中，就會為確認效果與修改而反覆出現，這類開發者與程式專案的互動關係在前面的篇幅早已談過多次，這邊就以二個專案的後期進度狀況做個小結。
回到期中的小組twitter專案，我除了將分配的功能項目確實完成外，也利用等待其他組員進度的時間，反覆以使用者的角度測試使用，把介面設計中不合理的部分提出來改進。 尤其是網站整體的RWD效果，儘管用Bootstrap能自帶根據畫面調整顯示效果，但若要追求在不同大小與裝置畫面上的體驗，仍得利用開發者工具與手動調整瀏覽器來測試，其中較繁瑣的是元件的排列與高度，前者需配合預設的分段點以免跑版或截斷，後者則因縱向變化得用media query手動設定不同高度維持介面比例，花許多時間反覆檢查到滿意，才甘願將成果向上提交。
至於期末的個人電商專案，原本應該隨著繳交與口試前的檢查完畢而結束，但經過二次口試與參考同學的後續進度(口試的部分後面會解釋)，撰寫測試用的程式後有助於提升後端工程師職能，我才決定投入時間將之前課程只略微提過的自動化測試，包含資料庫格式、路由動作控制、覆蓋率、CI/CD(自動整合/佈署)等全部補做，同開發期經反覆參考教案、範例與文件，以及多次卡關與除錯，花了半個多月才完成。 另外，由於是第一次寫自動化測試，生疏的情況下常常寫出來的測試結果不如預期，反而得靠被測試的專案確認測試本身是否正確運作，讓我想到如果未來要做先寫測試再開發的TDD(測試驅動開發)，搞不好到開發後期仍須用專案檢查測試。
總之，測試的概念貫穿整個開發過程，甚至「測試(的程式)也需要測試」，寫代碼除優先完成指定的規格外，更要思考目前成品帶來的UI/UX效果，盡可能地額外花心力尋找改進方案，才能持續為使用者提升產品品質。
思考歷程的省思與致謝
回顧加入AC的學習歷程，先後因許多原因一再推遲了完成所有課程的時間，但背後都有自己的考量，以在學習新事物與工作、家庭、興趣等取得平衡。
探索階段：進度與延期的取捨
去年(2019)初由於也剛開始全職工作，工作與進修都需要時間適應，想當初第一學期原本只期望評估自己對寫程式的興趣，後來又為進一步確認是否要轉職，多自修二個月，打好目標與技術基礎才繼續前進；第二學期結束時，原本預計直接接續第三學期進度，卻遇到家人長期住院，得多分攤照顧與家務，除了期末考，新進度也實在無法準時完成，但意外的先修經驗，卻影響我對後端開發的興趣，在重修初期有餘力設定額外目標挑戰。
挑戰過程儘管多有斬獲，卻因為前面的二度延遲，學期末時也已是年末，我得先花時間準備原先約聘全職工作的申請或去留，結果無暇在第一時間完成期末考。 但經過去年這段時間的探索，以及參考其他已經完成課程甚至轉職成功的學長姊經驗，似乎得投入更多時間，才能在學習進度有更接近轉職要求的表現，於是做了一大決定：新的年度改為全職學習與協助家務，並開始寫部落格補記學習心得。
衝刺階段：開掛的進展與自由
全職學習的今年(2020)與去年相比，根本有「開外掛」的感覺，沒有過去全職工作的時空間限制，可以盡所能的補完舊有與拓展進階進度。 第四學期開始前，我將重心放在複習舊進度與補齊部落格，除了將前二學期的進度看過一遍，也將這段從動念到立志的心路歷程詳細記述，以及額外瀏覽與嘗試一些未來可能用到的技術與工具(如Linux開發環境)。
正式進入第四學期後，更可以感受到全職學習的「外掛」時間優勢，尤其是作業繳交的表現。 與去年如學期三相比，原本平日只有時間將當周進度讀完與大致跟完實作，作業往往得在假日趕進度，甚至得靠AC延長繳交時間才不算遲交(因為同學也有類似狀況？)，如果有助教回饋的修改，形同要更久才能將一份作業「結案」，又因此拖到下一週時程；而今年學期四期初進度，基本上平日就能將作業做完，假日再研究助教的回饋建議，且更有空多嘗試幾種方法，今週進度今週畢外還有時間看選修內容(這時發現同學進度都較整齊跟上，發現他們多也是全職學習)。 至於期中與期末專案開發，由於規模遠超過以往作業，以目前能力若不投入大量時間，將難以兼顧完整與品質，若非全職學習狀態恐難以做出體面的產品，顯出「開掛」的必要。
考核階段：個人專案口試與修改
經過二月的期初課程進度、三月的期中小組專案，與四、五月期末個人專案開發，終於在五月底迎來課程尾聲的里程碑：期末專案口試。
這次形式剛好與碩士論文口試特別像，評審一樣是二位「校內」(AC助教)與一位「校外」(外聘業界開發人員)，流程也是對三位評審提問進行答辯；但由於時空間與人力等限制，口試者的報告改成預錄介紹影片搭配口試前一二分鐘簡介，場地是以線上會議進行，也沒有口試紀錄的規定(只能用空檔自行記錄重點，雖有線上錄影但剛好檔案毀損……)，且指導者(期末開發同主題分配的助教)沒有參與口試，以及最後沒有公布整體等第或數字的評分(只有三位評審個別表示是否認為通過)。
由於與三年前的口試模式類似較容易熟悉節奏，且自認專案有經扎實的思考才開發，絕大部分的評審問題我都能回應，最後也獲二位AC評審的通過認可(外聘評審的有些用詞不太能理解，可能是不像AC助教群的問題以課程出現的名詞與內容為主，且感覺他的標準更高)。
口試過程與結果至少看起來還算順利，但評審們也指出我專案整體性的評論與細項的修改方向：認同專案的完整性與使用體驗，但規模對小型專案而言過大，不少細節沒有處理好，一開始應該要縮減規模做到MVP(Minimum Viable Product，最小可行產品)即可，規模縮小但功能精緻、能表現個人設計重點的產品會更適合。 至於其他修改的建議細項，則可參考專案第二改版的項目清單，即是我在口試後一個月的主要進度(時程由於六月初剛好開發用的筆電故障，先花一段時間處理而延後，實際修改程式期間約半個月，其中最費時的是完整自動化測試撰寫)。
延伸階段：自主延畢補完必修進度
如同研究所的離校手續時程，論文口試與修改的告一段落，代表畢業的資格已在不遠處，但如果課程還沒修完，或是還有其他考核(如英語檢定)沒過，就不得不延畢把條件湊齊，而這也類似我沒準時六月正式進入求職準備階段的原因：自己還沒準備好要畢業，畢業前理想應完成去年因種種緣由沒完成的各學期進度(期末考與部落格)，以及學期四最後安排的技術概念與刷Leetcode畢業考，這也就是我七月初至八月中的主要進度，補進度。
在自主延畢的這段期間，各學期進度部分，除了七月中花一週多跑去寫買新筆電的系列開箱文(因難得換的是市面最新機種，可搶發第一手資訊，且以前就想過嘗試寫不同主題的資訊或技術相關文章)，先後將五月中只初步整理的學期三、四學習週記與作業文字初稿重新校閱，並補完學期三期末考專案與整學期心得文(還特別針對自學主題與展現後端興趣包裝與加長)，讓當初相當於啟蒙方向的後端部分有更加精緻的收尾。 但，好不容易補完前面學期的進度後，原本以為畢業只差一步之遙，眼前的畢業考卻可能是目前遇過最難且陌生的挑戰！
畢業考的題型算是實際面試的模擬考，技術考題的部分一共有20題簡答，雖作答沒有時間與參考資料的限制，但因為每道都需要將題意邏輯充分釐清、掌握關鍵技術概念、用自己的思考重述，光是作答時需要一再斟酌文意，很耗時間與腦力，更別提部分題目(程式碼運作、技術比較或延伸)無法直接上網找到答案，得瀏覽多篇資料、獨立思考或模擬測試才得出確定的答案。 也許因為沒寫過太多這類題目，顧慮的也太多，我分了好幾天才將20道題目寫完，得分換算為87.5/100(三題不完全對，一題明顯錯誤，剛好都在程式碼的運作解說)，剛好在及格(75)與滿分(100)之間，還算可以接受？
畢業考的另一部分，則是所謂的刷Leetcode，考的是演算法，相當於寫出達成特定功能的小程式。 雖然以前學期二、三的JS課程就有一些類似題目，但這裡既使都是標為簡單的題目，對目前的我而言根本不簡單，很多題目得上網查找不同人的解法，否則沒辦法作答，因只有少數人的解法能看得懂；有些題目乍看好像自己能解，結果自己能寫出來的代碼，不是運算超時，就是真的思考與測試很久才解出來，題目刷完只會自我懷疑......。
然而，若不強求一定要自己獨立解題，上網查詢這題可能需要的概念，或是其他人提供的各種解法，仍算得上充實與有趣，可以複習或新學JS的語法，以及比較不同解法中哪個較簡單、效率或容易理解，刷題這件事的意義至少不必要懷疑，要懷疑的是自己的功力是否有隨刷題進步！
畢業階段：謝辭式結語與未來展望
終於，離完成畢業前所有進度，只剩下現在這篇文章了，在此想續仿研究所的畢業流程，用簡短的謝辭對學習過程中遇到的人們表達謝意：
首先以群體為代表，最應該感謝的是AC(ALPHA Campamp團隊)，透過整合實體班期經驗與線上教學優勢，推出兼具理論鋪陳、實作練習與課後諮詢的網路開發課程，讓像我一樣非本科系的人也能系統性的習得程式/產品開發的知識技能，甚至透過互動啟發自學挑戰的情意，讓學習動力得以持續。 這邊也要感謝自參與AC課程後，同期課程的同學與助教，我也從參考各位的作業、留言或回饋意見，得到許多教案以外的技巧與資訊，大幅地擴展學習廣度。
再來是我學習過程，尤其後期互動較為密切的對象，要感謝的是學期四期中與期末專案同組合作開發、互相支援、提供諮詢的同學與助教，使我有機會提早體會產品開發過程的協作溝通、同儕支援、前輩指導等經驗，也才順利完成專案進度並獲得支持與成就感，踏出通往工程師實務的一大步。
最後，當然要感謝家人的包容，願意接受我暫停工作全職蹲在家裡準備轉職的決定，待未來轉職成功工作穩定後，必然會盡可能地在經濟上回饋家庭。 我在AC學習網路開發的課程在此正式告一段落，緊接著便是積極準備求職的階段，希望能在未來的一、二個月內，特別是在十月中旬之前，便能將轉職成功作為給自己的一份生日禮物，期許自己能以網路軟體工程師為起點，在科技/數位領域找到未來的發展機會。
