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