回歸後的第一次結案復盤

這是我第一次接與政府相關的案子，但也有可能是最後一次，我真的比較少接觸公家機關的案子 XD

這個案子是翻新一個政府的形象網站，裡面包含前台與後台，我們是承包政府機關廠商的下游，承包的廠商（以下稱業主）會讓發包的政府機關（以下稱機關）選擇想要的前後台模板，後台沒有 UI 設計稿，前端使用 template 預設的樣式就可以，前台有設計師給予設計稿，設計師會依照業主選擇的模板來做出相似的設計。

前端夥伴加上我是兩位，我主要負責前台跟部分後台，另一位夥伴負責後台跟部分前台，後端也是兩位（其中一位後端還身兼 PM，真的是難為他了）。

• 掌握多國語系的運作。 我通常做的都是後台的案子，比較少碰到與前台相關，這次首次接觸到多國語系相關的需求，了解到多國語系的運作模式，還有一些地雷，比方說「@」特殊字元的地雷，我甚至套用到我自己的技術部落格上。XD

• 跳脫 Option API，投入自由的 Composition API。 然而在使用 Vue 的時候，我因為之前的經驗，多半都是熟悉 Option API，這次完全掌握 Composition API，我覺得非常高興，真的是再也回不去了。

• 跳脫 Vuex，初見 Pinia Store。 乾淨的 Composition API，連帶學習 Pinia Store，擺脫 Vuex 冗長的 API。

• 設計稿產出時間過長，壓縮開發時程。 原本這個案子從七月就開始啟動，但到接近八月底才出首頁的設計稿，原因是業主需要跟機關不斷確認設計細節，而導致前台的設計稿接近九月中才完整產出。（當中我們的 PM還在群裡面問我們這個案子現在是 pending 的狀態嗎 囧）

• 前台設計元件與機關選擇的模板不相符。 我猜想，可能是因為設計端在短時間內急迫性產出稿件，所以產出的設計稿並不如我們預期使用機關所選擇的模板。

• 高級長官介入，在驗收階段期間進行大量修改設計。

  後來來不及在九月中業主第一次提案的時間去呈現給機關，在十月初我們完成第一次交付，接著是漫長的驗收階段，而在驗收期間內機關不斷反饋給業主要修改的部分。（當中有一張圖我至少重置五次以上⋯⋯）

• 時程與品質一樣重要，遇到困難的地方主動溝通尋求幫助。 在第一次提交的時候，那時尚有足夠的時間去規劃病開發，但在驗收階段時接收到大量修改，重複開發導致心理很疲憊，但更多是我有這些修改的心理壓力。在顧慮時程加速開發，並沒有把程式碼品質顧好。 既然我已經答應並接受修改，如果有異議我當下應該要提出延長時程及相對應的成本，才不會在後續修正的時候忽視品質，讓自己改得很委屈又不開心，這是我需要改進的地方。

• 在沒有設計稿的情況下，前端共事的夥伴應該更有共識。 後台沒有設計稿，導致我們在製作後台時有兩份完全不同的 UI 呈現，這個地方我們在開發前應該要先確認相關需求，確認哪些 UI 我們應該要一致，才不會導致一個後台頁面，兩個地方不一樣的情況。

• 發現設計模式不同，主動與設計師進行討論。 這個案子中我們跟設計師都是透過業主交流，比較少直接交流，然而在發現首頁的設計與機關指定的模板差異很多的時候，我們應該主動跟設計師要求至少一次的線上會議，這可能會幫助我們的開發更加順利。

人都是在一次次的經驗中吸取錯誤，逐步成長，我會記取這次的錯誤，讓自己下次不要再犯。