前言
時間過得很快，不知不覺的我就滿月了。期間不斷進行的是與團隊成員的磨合，而之前提到的 Side Project 也如期地進行中。
畢竟是優先度較低的 Side Project ，所以對於其他團隊成員來說，都是運用比較零碎的時間來做，主要還是處理主力專案。
而我因為還沒正式接觸到公司專案，自然重心是放在這個 Side Project 上。
磨合 & 心境
如上面提到的，這是個團隊的 Side Project ，意味著可以自由地玩很多新東西。
Team Leader 決定導入 prettier 並且提交 commit 時觸發 prettier 的自動格式化，最後在 GitLab 上 進行 CICD 的檢查，達成團隊的 Coding Style 一致。
然而在開發習慣上，因為之前都是單兵作業，所以比較少顧慮到可能會有其他團隊成員來維護同一份 Code 的情形。
這也導致了寫某些程式時缺少了比較長遠的思考，很多部分都是後來發現「不能這樣寫、這麼寫不夠好」而又回頭修改。
團隊基本上是使用 Angular 搭配 TypeScript 進行開發的，而我之前在學習前端時都是使用 JavaScript ，在思維上有一點差異，這也是我目前需要學習與磨合的地方。
舉例來說
在敏捷開發 Sprint 的第一周，我負責的是串接某一支自己 Mock 出來的 API，裡面的內容雖然我有整理好一份文件，但呼叫 API 後的內容仍然只有我一個人知道，團隊的其他成員完全不知道呼叫這支 API 後會回傳什麼結果，導致後續維護不方便。
因為：
- 如果要知道這支 API 會回傳什麼就得呼叫它，並印出來
- 翻閱文件
但這對之前的我來說是一件很正常的事情：
接 API 如果不知道內容是什麼，印出來不就好了嗎？或者看文件也行，上面都有寫。
這樣的確可以，但對團隊來說，這還不夠好。
所以實作一個 class 並且透過 TypeScript 將該變數型別設定為它，如此一來就可以在接到 API 傳來的資料後，使用「.」看到這個物件下有什麼屬性、方法能使用。
搭配適當的命名就可以讓維護的人明白這支 API 會回傳的內容有哪些。
而這也只是與團隊磨合的一小部分而已，我還必須持續透過這個 Side Project 了解到許多團隊協作的眉角。
心境
在開發上當然也遇到了一些困難，自己歸納後最主要的原因果然還是：
- 不夠熟悉 Angular 以及 TypeScript 的原理
在 Sprint 的第一周時，我先行使用原生的 JavaScript 快速的把原型給搭建出來，像是 Mock API 、 GitLab API 的串接整理、圖表繪製等等…，過程都蠻順利的，也很少麻煩到團隊內的前端同事。
但在實際轉換成 Angular 時，卻遇到了不少自己想不透的問題需要請教同事，這讓我有點不好意思。
像是上面提到的協作問題、舊版本
ng2charts的 Bug 、寫測試、還有一些特殊名詞 & 觀念問題。
最終總算是在交作業的前一天完成了，幸好同事也不厭其煩地與我一同排除掉這些問題，真的是非常感謝。
但我也希望自己能夠早日解除這種狀態，實在是有點擔心自己試用期不會過 (汗)
小結
其實還有很多族繁不及備載的芝麻蒜皮小事，像是命名與程式寫完之後該怎麼調整才能讓結構看起來易讀，這些都是值得我去努力的東西。
然後也借了一本無瑕的程式碼 番外篇：專業程式設計師的生存之道，書名看起來就像是我這輩子絕對不會看的東西，但我終究是借來看了。
那個當初連 「Hello World」 印出都有困難的人去哪了？
一個人可以改變這麼多，每當回頭想起，我還是覺得很不可思議。