先從第一個月開始，身為一個新人，本來預期會有個圖學大佬帶我，好好教教我學校學的東西跟實務上的差別，畢竟一開始招我進來就是因為我會OpenGL，但是在公司待了兩個星期慢慢發現，原來就是因為公司沒有人會OpenGL才找我進去，因此我就是公司裡面最懂的人了，當然有一些主管也有一些背景，但並不是專門的，總之，往好的方面說就是在圖學方面的東西我說的算，往壞的方面說，我不會也沒有人可以討論。
只是幸好，實務上要用的東西基本上只要大學上課有認真學基本上知識量都是夠的，而講到OpenGL，公司實際上需要的是寫C/C++和OpenGL ES在Linux上，除了我之外只有一個工程師稍微會寫，會寫的程度大概就是把GL當作API使用的程度，而目前可以運行的版本就是由他來維護，但是目前的版本內部相當繁複，缺乏文件的情況下不好讀，而且GL似乎也是當作API在用的。
因此，我進來第一個月的任務就是重寫整個Rendering Engine，幸好研究所的時候有trace過Blender內部eevee的code，並且以我對GL怎麼運作比較有效率的方式去寫，簡單來說就是用VBO(OpenGL ES 2.0沒有VAO)，然後rendering獨立成一個thread，儘量減少CPU跟GPU的溝通，雖然這些對於圖學來說只是標準動作，並沒有用甚麼厲害的技術，但就結果來說，比過去的版本快多了。
總之，經過一個月我大概完成了rendering engine並且後續也裝上了車，雖然當下我沒看到，但是之後因緣際會下也親眼看見在車上的效果，而這些居然是我一個新人在第一個月做出來的，當然，我只是負責最後端的rendering，但是這完全是我預期外的結果。
而一切看似順風順水，整個生活節奏也大概習慣了，每天早上7點起床，7:40左右出門，騎機車大約40分鐘到公司，也就是8:20左右，工作大約加9個小時，也就是大約17.30就可以下班。
但是在入職後一個月後的某天，照往常下班時騎在堤外便道上，然後，我的印象僅此而已，之後就是模糊的記憶，似乎坐在救護車，似乎撥打電話給父母，似乎，我沒有記憶了。
講是這樣講，事後回想起來就是發生車禍的前後記憶消失了，幸好是醫護人員的及時趕到，幸好是家人在我的身邊，也幸好神明有保佑吧。根據附近的監視錄影器畫面，我似乎被從堤防上下來的機車撞到，原因是他直接切進主幹道，並且要到我的對向車道，因此從我的視角他應該是從左上方突然出現，我沒有反應的時間。
事實上，我個人本來就對於騎機車有點排斥，可能在三重看多了，那種橫衝直撞的豪爽，讓我就算有了駕照也不常騎乘，但是當兵完後為了找工作以及省去工作地點漫長的通勤，我終究也是慢慢的熟悉路上的狀況，當然我也是儘量走在簡單的路線，守著可能有些許不合理的速限，至少沒有收過甚麼罰單，就在我覺得台灣交通還沒那麼糟時，我錯了。
總而言之，儘管搭乘捷運月票約為1200，相比起油錢更加昂貴，時間也從40分鐘拉長成90分鐘，但是我終究還是決定如此搭乘，可能每個人都有適合的交通工具吧，至少在我的經濟能力範圍內，因此，從事發後大約3個月後，我幾乎不再騎機車了，儘管感性上我壓根沒有車禍的記憶，但是理性上，我知道這次只是失去記憶，下次可能失去更多。
再回頭來講講事故後工作上的事吧，本來以為會要一直維護我寫的Rendering Engine，但後續似乎沒有發生大問題，也就由其他人來接手，同時團隊也希望改成用Unity。
雖然在大學、研究所期間有蠻多朋友、同儕都是用Unity，但是我幾乎不太使用，基本上都是用OpenGL從頭刻，原因純粹是因為我認為OpenGL，或者說基礎圖學的東西更少資源，因此想在學校儘量學，而Unity或者是其他引擎則是大多數產業界乃至於學術界都有在使用，相對資源廣泛很多，因此我本來就打算出去工作的時候在順便學，另一方面，我猜會了C/C++和OpenGL基本上C#和Unity應該也能很快上手。
為了讓我快速上手，公司就把我丟進別的team裡面參與開發，進去之後才發現他們用的就是所謂的敏捷開發，以Sprint為單位來設定目標，然後每天早上開站會確認進度，當然實務上沒有這麼高大上，其實就是先跟Scrum Master確認Story，也就是兩周要做的大方向，然後就是每天線上開早會。
在三個月後一些應該會的東西基本上都摸得差不多，除了Unity腳本、shader之外還有Git的使用，因為以前就學的時候雖然有用過，但是基本上是把Github當作是雲端硬碟使用，只會最簡單的push, pull，遇到conflict就直接整個刪掉重pull，但至少現在基本的指令都會輸入，就算不會也找的到資源去看。
後來等到幾個Sprint結束，我負責的部分大致告一段落後我就被指派要負責寫一個完整的unity專案，雖然當下覺得有點趕，但也只能硬著頭皮上了，除此之外，因為我沒有開發過一個大型專案的經驗，或者說沒有設計架構的任何知識，因為我過去基本上的開發邏輯都是純C，頂多就是一點物件導向，因此程式通常不會太大。
因此我開始到處找介紹架構的網站、書籍，但是總有種隔一層紗的感覺，道理我都懂，但是為甚麼要這麼做？知識脫離了應用時變得格外難懂，因此後來我決定從應用的角度找資源，而非是理論的角度(找書)，也就是直接找怎麼開發Unity專案的教學。當然，網路上的資源有很多，也有像是我給我這種初學者看的教學，但我總感覺這跟理論有所差距，直到我看到阿星大大的影片才開始感覺到一些東西，雖然很多東西未必一開始能懂，但是都有解釋為甚麼這樣寫，因為書上常常教的是如何寫，但我並不知道這麼寫的理由，這樣寫要追求的是什麼目標。
也因為算是完全屬於我自己的專案，我基本上可以完全控制架構，因此也開始嘗試TDD (Test-Driven Development)，甚至到後來也有類似DDD (Domain-Driven Design)的寫法，雖然我還是算個初學者，同時其他同事似乎都沒有這樣的經驗，所以我也有點沒把握，其餘的部分等我自己順過整個邏輯在分享吧。
我簡單的結論就是，我在用這個架構的目標就是能夠容易替換class，替換包含了新增以及刪除，儘量避免東西不會因為改A壞B，或者能夠快速抓出在哪裡出問題，當然，最一開始還是會寫prototype確保整個理論是正確的，這個的重點不在於怎麼寫可以達到上述這些，重點在於對於一個專案有甚麼是重要的，而達到這些目標的手段有很多，甚麼架構都可以。實務上來說，我有了為何使用這個架構的目標，所以很多東西的寫法都服務於這個目標，也就許多東西順理成章了。
除此之外，團隊也有在鼓勵在工作流程中使用AI，例如有許多人的報告會提到某些點子是來自於chatgpt，或是後來使用copilot來節省時間，值得一提的是，雖然英文不太好，但偶爾還是需要跟外國人溝通，我只能拿出我多益不到550的英文上了，事實上，大概在年後就要去底特律出差，當然不只有我一個，但是想到我的口說跟聽力就冷汗直流，之後有機會在分享吧XD。
