不斷挑戰自己，就是不斷超越自己

在這份工作中，我從習慣了後端艱難的架構到能夠很自在地完成需求，甚至可以提出優化，這也是我最愛的部分。我從以前就會一直協助公司優化動線、流程等等，軟體業才是有更多這樣的機會，而這也會是我的堅持！

Day11 回顧

在 Day11 中，述說了我訓練期間發生的事情，包含一個後端系統，跟一個前端官方網站的實作，也訴說了我的轉變。而這篇就要寫我正式開始接觸公司 B2B 產品的部分。

入職 2.5 個月：提早脫離訓練期

我在 2020/06/15 加入了公司，預計的訓練期是到2020/09/15。然而，可能我表現得不錯，老闆讓我在9月初就提前脫離訓練期。這不僅讓我感到驕傲，也意味著我要開始深度參與公司的產品開發。當然這也意味著加薪。

初步的工作內容與目標

在這間公司因為是一名全端工程師，所以很自然的是前後端都要接觸，自然的就是我們要從資料庫開始逐步地把資料拉出來，然後跟討論好應該要開什麼樣的 API 格式，並且完成。接下來連前端部分都是自己串自己做好的 API，我覺得這樣的模式有個好處是因為自己串的關係，所以出問題也知道後端該怎麼改，就可以再去修改。

公司產品主要技術：
前端：React、React Router、Redux、SCSS、Jest
後端：Express.js、TypeScript、MongoDB、DDD 架構、Mocha
其他：GitLab、GitLab CI/CD、Zeplin

前端方面是回到使用 class component，所以就繼續跟 life cycle 奮戰
人生第一間公司就立刻挑戰 TypeScript 真的是人仰馬翻，幸好只有後端是 TS。

那些初次挑戰的 issue

• 提前脫離訓練期並投身產品開發

• 我的第一個Bug：解決CORS問題
  一開始，我被分配了解決CORS問題的任務。這實際上是一個後端轉址問題，需要我改變資源請求的方式。經過仔細閱讀相關文件，我很快就解決了這個問題。

• 獨立解決播放器Bug
  解決完第一個問題後，我獲得了更多的信任。接下來，我被分配了一個與播放器相關的Bug。這次，我沒有同事的指導，需要自己找出問題並解決它。雖然過程中遇到了困難，但最終我成功找到了問題點。

• 前端部分開發新分頁：回到Classical Component
  不久後，我開始參與新功能的開發。這次我負責開發產品的一個新分頁。由於公司主要使用Classical Component，這讓得回到過去的經驗中，與生命周期方法一起工作。

主要工作內容

這間公司主要是做監視器系統整合，所以我們經常要做的就是從資料庫抓出攝影機，或任何需要的資料，然後建立專案給予 B2B 的公司使用。

其他部分則大多數都是在完善整體系統的架構，像是處理一些使用者授權的部分，因為是 B2B，所以是對應公司的，公司當然就需要有辦法授權給他底下的員工，按照員工的等級不同要給予不同的權限，以及其使用者管理等等，都是我在這份工作上的責任。

接下來就會寫寫一些我在這間公司的主要貢獻以及改進

持續的小貢獻

基於我的愛好，我很喜歡優化組件，所以為此，我也做了一些不錯的改進：

• 開發了數個後端 api 跟前端介面
• 開發出數個共用組件，以節省開發時間
• 優化整頁式表單組件樣式以及架構，並與設計師溝通正確組件樣式，使之可以輕易新增或更換欄位

更有效率撰寫 SCSS 的方式

為什麼會產生這樣的問題，最主要就是因為公司在 RWD 方面的規劃是以 1080 為分界，以上是按照比例放大，以下則是按照設計稿來製作(設計稿 1080)，但在我當時寫了幾個 issue 之後，我注意到為什麼我們每次寫法都要寫兩次，這樣很奇怪，也很重複。

所以我就開始研究一下 SCSS，我注意到有個變數的功能可以使用，甚至還有函式的功能可以使用，於是乎我就開始去研究 SCSS 的官方文件，然後我有注意到這個 SCSS 的語法跟 JavaScript 是完全不同的。所以會有些看不懂，怪不得之前公司沒人想到可以這樣用。

但是基於我愛研究的個性，我就下去研究，然後我就發現，其實我們只要寫好一套就好，然後再利用函式的功能，可以傳入變數，這樣就可以達成只要寫一次就好。然後剩下就是讓瀏覽器根據 view point 去呼叫那個函式傳入對應的變數即可，達到 RWD 的效果。

這樣我們就可以省下將近一半的工夫在慢慢調整 CSS。

優化錄影讀取效率

與其他同事協同改善多頻道錄影畫面讀取效率，讀取秒數從 5 秒以上變成 1 秒內讀取完成。
這個印象有點薄弱，因為當初不是我的 issue，而是另外一個同事的工作內容，只是他來找我討論。

公司的錄影系統是提供保全公司的，所以經常會有一個畫面要顯示 8 個甚至 16 台攝影機，所以會有大量的 loading。也因為這樣，變成經常失敗，然後失敗之後再重複嘗試，直到成功。所以讀取起來都會特別的久。

最後是我一邊查資料一邊找，意外發現瀏覽器有個限制是一次相同的 api 不能打太多次，否則多的就會被取消，然後我印象中我們打 api 都是利用帶 body 來區分的，所以會變成一次打 8 ~ 16 隻相同的 api。

同事則是去測試發現好像是真的這樣的問題，所以就想了個辦法，就是在 API 後面利用 query string，帶一些隨機碼即可。

不過這樣是比較屬於刻意閃過瀏覽器的限制，比較好的做法後來有注意到是要升級成 http 2 即可。
但這個是大工程，所以當時沒有做。

離職階段

自我評估

在經過了快一年的努力，我在公司產品上也能夠持續的建立完成功能，甚至還可以提出一些優化方案。而我是不是已經沒什麼進步空間了？另外一點是我之前是從化工產業無縫接軌到這間公司的，這樣有點瘋狂，但這陣子下來也有點累了，好想休息。

決策過程

1. 公司前端產品持續使用 class component，而且也堅持要使用，尤其是當時的產品 owner，即便公司版本號本身就已經超過 React 官方推薦「不再寫 class 推薦改寫 hook」的版本了，而我身邊的朋友都紛紛開始說他們公司使用 hook 了，也讓我害怕起我會不會與市場脫節。

2. 公司環境非常好，有餅乾有零食，甚至還可以跟公司自告奮勇說要去幫忙採買，老闆很強(但只做後端)也很大方，大概兩個月就有一次聚餐而且都吃很好(600+元/人)，我好像有胖了。但就是這樣的環境讓我懷疑起，我是不是過得太輕鬆了，導致我的進步開始緩慢。況且我不會想拘泥於一間公司，我加入這行就是希望有所成長的。

3. 公司的前端產品處於一直不停的開發功能，但有些我希望做的改進，產品 owner 沒興趣，導致我很像機器人，一直不停地複製貼上改一改。

4. 在台北開支非常大加上我有一些債務，所以基本上，我在這間公司上班，幾乎是沒賺什麼錢，甚至有幾個月還倒貼，尤其是最開始開車上班。雖然我還是有透過自己的節省個性，使自己可以吃飽又存到一些錢。但誰都希望賺更多，對吧

提出離職

後來我寫了一封一路順風的信，也就是一種用大家都同意的主題、內容、事務、活動去溝通的方式。結果老闆的反應是很不捨，甚至設計師也問了我，不考慮再留嗎？

我知道這邊環境很好，但我還是決定要離職了，因為過得太安逸是不太好的。而且在此之前我也有點想休息一下了。

結語

在這家公司工作的時間裡，我學到了很多，也做了不少事，更體會到「適才適所」的重要性，我的位置放對可以發揮更好的功能。而我覺得我還能做得更多，所以我想找一個新的機會，讓我能全力以赴。我喜歡解決問題，喜歡看到自己的代碼能讓事情變得更好。未來，我希望能在一個能讓我發揮，並且我也能為它加分的地方工作。

下一篇會寫輕鬆一點的內容，會寫寫我在這份工作之餘的生活狀況，讓大家看看一個初階工程師的生活

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

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

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