透過已知的障礙、自由及目的，便可以在人生的各種遊戲玩得更好

我很喜歡這句話，因為這句話告訴我們，在知道了有何種障礙以及有哪些自由的地方可以發揮後，就可以根據一個特定的目的，做出更好的改變以及創造，就可以使得任何事情做得更好，也就是遊戲玩得更好的意思。這句話也是觸發我行動改變自己人生的其中一句話。

回顧 Day16

在 Day16 中，我提到了一開始在前後端合作發現的問題點並且有用間接的方式去建議使得後端部門有了不少的改變，在日後的合作上，我們也越來越順利。於是乎我把目光放到現在的前端產品上，在逐漸完成了一個又一個的需求後，我開始產生一些可以加速這樣開發流程的想法，而這篇就來寫寫當時的狀況吧。

當時狀況

這部分曾經在 Day15 已有詳細的論述，但在這裡我會做簡要的回顧並加以補充。

我的狀態

經歷： 在一間軟體開發制度算完整的公司任職全端工程師，所以對於前後端、CI/CD 等都有一些經驗。
coding 風格： 我寫程式是屬於 clean code 的寫法，也就是程式碼即文件，所以會非常在意函式取名跟變數名稱跟可讀性。當然如果必要的話，也會在需要的地方加上一些補充。

前端產品

我們前端三人，負責的是一個涵蓋多個行業客戶的會員點數管理系統的後台。這個後台系統充滿了各種表單和選項，用於管理如優惠券發放、活動時間等多個方面。

所以會有相當多不同的頁面，都是為了客戶可以管理他們的優惠活動。

各種任務

被給予的任務

大多數就是一個新的行銷活動，畢竟行銷活動常常有很多不一樣的需求。所以我們就必須要一直不停的實作功能，而在實作這些功能中，我越來越了解了整體的架構是什麼樣的。

也開始學會很多技巧，知道了該怎麼去快速找出需要修改的地方等。

甚至也注意到裡面的表單是使用多層次的表單來進行個細緻的設定，例如：可能有彈窗的彈窗的彈窗的彈窗的彈窗，這類好幾層的彈窗。

也由於整體架構設計時，似乎沒有多加考量，這也導致了一些問題。

產品問題點

1. 多層次彈窗的開發困難：由於使用了多達五層或更多的彈窗表單，每次修改最內層的表單都需要整頁刷新，再從最外層逐一點選以確認變更。會這樣也是因為當時使用的 React 版本的熱加載會刷新整個頁面。

2. 缺乏模組化設計：目前的架構沒有模組化，導致每個新頁面都是通過複製和貼上來創建的。這不僅增加了維護成本，也使得各頁面只有主題和表單內容有微小差異。

3. 重複頁面過多：由於頁面重複性高，每次需要修改或尋找特定頁面時都需耗費大量時間。

4. 產品難以使用：本來要給客戶使用的後台，但因為太難用，後來聽說客戶都是直接請公司的 pm 幫忙設定。

5. 沒有使用生命週期：公司雖然是使用 class component，而我實際去看後，發現只有用到 componentDidMount 而已，然後大部分都是只有使用 state 跟 props，然後就沒了。

6. 其他問題：除了以上幾點，還有其他多種問題，這裡就不一一列舉。

被給予不一樣的任務

在這個階段，儘管我察覺到一些流程上的不順暢，但我仍然持續接受新的開發需求並成功完成它們。這時，設計師似乎注意到我能夠順利地完成與過去不同類型的需求，因此開始提出更多創新和複雜的設計。

值得一提的是，過去前端開發主要是由後端工程師兼任，因此他們只會使用一些基本的前端技術，例如使用 Ant Design 來實現基礎表單和彈出視窗。然而，我後來接手了多種不同類型的設計需求，包括：

1. 連動式表單：就是 a 表格有了選擇後 b 表格會只顯示出跟 a 相關的選項
2. 動態表單：通過後端 api，取得資料後，在顯示出下拉式選單

後來甚至越來越腦洞大開，開了一些原生 Ant design 沒有可用元件的需求，變成我要直接用 styled-component 去刻出來，幸好對於原生 css 本來就很有把握的我，都處理得來。

面對需求不明確的挑戰

在我接手的任務中，需求通常是以 Excel 表格的形式提供，其中只包含了功能的概念性簡述。這樣的情況導致需求界線模糊，使我不得不頻繁地與產品經理（PM）和設計師進行多輪溝通。更令人困擾的是，即使是他們也常常對需求持不確定的態度，這無疑增加了項目的時間成本。值得注意的是，這似乎是公司內部流程的固有問題。

設計資源的不足

儘管公司有設計部門，除了大部分需求如同前面說的那樣外，偶爾也會提供設計稿，但他們提供的設計稿通常只是 JPG 格式的圖片，所有的 UI 實現工作都落在我身上。這不僅增加了我的工作負擔，也讓整個開發流程變得不夠高效。

其他人的看法和建議

我曾經在工程師群組中詢問過這樣的工作模式是否正常，結果得到的反饋是相當負面的。有人甚至建議我應該儘快尋找其他工作機會。

成長與信任

獲得同事和主管的信任

隨著我成功完成越來越多的需求，甚至也可以完成具有高度變化性的需求，我逐漸贏得了主管和同事的信任。

環境造就提升

由於工作環境中缺乏可供我詢問的對象，於是我就萬事依賴 Google 進行問題解決和資料搜尋。這一過程不僅鍛煉了我的問題解決能力，我的 Google 跟解決問題和分析能力，又再次提升了一個檔次。

成為問題解決的中心

最終，同事們在遇到前端相關的問題時會首先找到我。甚至一些只是稍微與前端相關的問題，也會被引導到我這裡。

印象深刻的一次經歷

其中一次讓我印象最為深刻的是，主管在處理一個正則表達式（Regex）的問題時遇到困難。他無法獲得預期的結果，於是來找我討論。儘管他最初對我的分析持懷疑態度，但經過我進一步的 Google 搜尋和資料確認，他最終接受了我的觀點。該問題主要涉及到 PHP 和 JavaScript 中 Regex 的使用差異。經過一些細微的調整，問題得以解決。

自信的積累

這些經歷不僅增強了我在團隊中的地位，也讓我對自己的能力和價值有了更多的自信。

結語

在這份工作經驗中，我不僅展示了自己獨特的能力，也贏得了同事的信任和尊重。儘管我與兩名同期入職的前端工程師相比，我的工作經驗較短，但最終他們也開始來找我解決問題。

靈活應對與自我提升

後台的程式碼即便是有點問題存在，但也不妨礙我去完成需求，我可以感受到自己是一個可以對於各種障礙能游刃有餘的處理的人，在這份經驗中，也影響我之後的工作能力。也確實我在這些跟往常不同的挑戰上，確認到自己對於程式開發是有熱愛的，而且也很願意接受這些挑戰並且完成他們。

不拒問題，尋找亮點

這份工作也讓我確認了自己對程式開發的熱情。我不僅願意接受挑戰，還能在過程中找到創新的解決方案。即便我說程式碼有很多問題，我也在深入學習他們的語法之後，也有看到一些特別的語法，我甚至有學起來，多了解一下不是壞事麻。這點也影響到我後來在使用 useEffect 呼叫 api 的寫法，因為我後來研究出一個使用 IIFE（立即調用函數表達式） 的寫法，個人認為寫起來非常的漂亮。

甚至我現在公司的資深工程師看到後，他也跟著用。我很慶幸我是個任何情況下都可以有所領悟跟發現的人，所以我才可以這樣逐步累積之後，使得自己越來越好

在下一篇文章中，我將分享我在前端開發方面的各種改進和心得，希望你會喜歡。

文章就說到這，有什麼想法或問題，歡迎隨時找我聊聊！

這篇文章也會同步發在 medium 上，如果有興趣歡迎追蹤我。

medium: https://medium.com/@hugh-program-learning-diary-js
email: u88803494@gmail.com