成功只是個開始，失敗也不是終結：重要的是持續改變的勇氣
— Winston Churchill
自從成為全端工程師後，我選擇專注於前端開發。第一份全端工作的多面性優勢很快就在這個職位中顯示出來。
在 Day15 中，我分享了我在第二份工作的初期狀況。我發現該公司是一家典型的接案公司。儘管如此，我仍選擇接受這個挑戰，因為接案公司提供了極佳的自我挑戰和獨立負責的機會，這些都將是寶貴的經驗。這篇就來介紹我第二份工作狀況以及我遇到的挑戰。
上一篇文章沒有提到公司使用的技術棧，所以這次來詳細介紹一下。
值得一提的是，這裡的 React 版本比我之前的公司還要舊，因此 Hook 還在測試階段。
Ant Design 則是我之前未曾使用過的UI框架。
由於我沒有後端的存取權限，所以對其他技術不太了解。
在陸續完成幾個工單後，也逐漸地接觸到一些後端，然後發現了不少狀況。
問題描述： 一旦需求確定，前後端會同時進行開發，導致前端在不明確後端API規格的前提下進行開發。
解決策略： 我通常會先與後端進行初步的API規格討論，以確保開發的順利進行。
問題描述： 後端聲稱 API 已完成，但實際使用 Postman 測試時發現無法獲取資料。
註解： Postman 是一個專門用於 API 測試的工具，允許用戶直接發送 HTTP 請求，而不用透過瀏覽器。
解決策略： 我會持續與後端溝通，追蹤問題並確保其修復。這過程中，我發現自己更像是一名測試工程師，因此也開始主動提出改進建議。
除了直接解決問題，我也進行了一些間接的改進。
例如，我在某次合作中，向後端同事展示了如何使用 Postman 進行 API 測試，並解釋了瀏覽器的一些限制，如CORS，使得他們了解，為什麼要先用 postman 測試以及先使用 postman 測試的好處，這些努力最終使得整個團隊的開發流程更為順暢。我在想或許之後有機會可以寫一篇文章來介紹這個主題。
參考資料：
我之前寫過的學習筆記的瀏覽器只是一個程式的部分：瀏覽器只是一個程式
了解更多：網路基礎概論： 淺談 API、網路基礎概論：好用的工具與指令
經過這些努力，我發現後端同仁在說 API 完成前，會更加謹慎地進行測試。甚至也有看到一些同事採用我給予的建議「先溝通好 API 規格後，才進行開發，並且邊開發邊用 postman 測試。」
雖然我不確定他們是否增加了其他測試項目，但至少我知道我的貢獻帶來了正面影響。
在持續的工作流程中，我觀察到一些後端的問題並向主管回報。部分問題得到改善，但仍有一些持續存在。接下來就簡單列出：
協助優化API錯誤回應機制： 與後端團隊合作，確保API錯誤訊息更符合通用規範，提高了客戶使用體驗。
改善資料庫錯誤處理： 推動後端團隊改進資料庫錯誤的處理方式，以提高系統的安全性和穩定性。
我有後端開發經驗，尤其我也用過 PHP，這讓我能與後端成員順利交流。其中一名後端成員和我經常討論，因為他也會寫JavaScript。
我提供了一些改進建議，他們大多數都有採納，這也使得後端的工作流程變得更為順暢。一些成員甚至會主動與我聊天，整體氛圍相當不錯。
在這間公司遇到了不少挑戰，畢竟跟前公司那樣非常有制度的比起來，就像是天平的兩端一般，不過也給予我很多不同方面的挑戰，我自己在想當時能跟一些後端有良好的氣氛，也歸功於自己有提出一些不錯的建議。
在這份工作中，自己也體會到溝通的重要性，真的要好好扎實的溝通，才可以讓對方聽進去。但我認為之所以可以成功，也歸功於自己平常有在持續精進的學的。我在這段期間為了增進自己的溝通能力去參加了一些課程，那課程讓我們演練的一些溝通的各種狀況，並且讓我學習到如何維持良好的溝通，這導致我後來的溝通能力大增。
也應證了我之前學到的「工程師這份工作除了專業之外，溝通也很重要」的這句話。
在這份工作中也逐漸地讓我發現到自己的能力，算是很不錯的，所以我也慢慢的恢復自信。
下一篇，會介紹我針對前端方面提出的各種改進跟進步，希望你換喜歡這篇文章。
文章就說到這，有什麼想法或問題，歡迎隨時找我聊聊！
這篇文章也會同步發在 medium 上，如果有興趣歡迎追蹤我。
medium: https://medium.com/@hugh-program-learning-diary-js
email: u88803494@gmail.com
iThome鐵人賽
看影片追技術