[工程師轉職]Alpha Camp全端開發, 學期二心得
學期一結束之後，很快的又經歷了為期兩個月的學期二。整體課程質量比學期一豐富相當多，感覺很扎實地進行了一段修行之旅。
若要說，學期一就很像是以前學校的社團體驗課。就帶你來看看環境，認識認識寫程式是怎麼回事，然後做幾個小練習試試興趣。
而學期二開始就是本格的在訓練蹲好「全端開發」的馬步。開始真正的用JavaStript做出可執行的網頁應用。不像學期一，只在終端機上面用文字反應功能。成功的在網頁上做出可視的作品，那個成就感與滿足感也是遠遠超過學期一的。
● 從Float流切版到FlexBox與前端框架
最開始上學期一之前，我根本不相信，不用Dreamweaver要如何切版。後來學會了怎麼撰寫簡單的HTML與CSS，也學會了早期使用Float的切版方式。
學期二開始，更深入的講解了Flex與Grid這兩種較新的切版技術，跟著課程的引導，理解原理之後，開始進入 Bootstrap 框架，可以更快速的打造出一個頁面。
這讓我有更完善的技術力，可以將我腦中所想的畫面給如實的呈現在網頁上。學到後面我甚至開始妄想說，這世界上已經沒有我切不出來的版了XD
● JavaScript與DOM操作，建立更扎實的程式能力
學期二終於可以學到「如何使用程式語言去影響網頁的呈現」。從最基本的JavaScript觀念教學，DOM操作實戰，以及如何處理資料......等各種演練。
想起以前學生時代，跟風用Dreamweaver寫網頁，那時候很多JS功能完全都是複製貼上，根本看不懂到底是甚麼意思。而現在我可以清楚的知道每一個指令是幹嘛的，不僅能看懂網路上別人分享的script。更能靠自己寫出自己的script來操作網頁功能。
除了視覺相關內容之外，也進行了很多演算法的訓練，寫了摸彩箱，寫了計算機，也學會了怎麼寫Search功能。感覺戰鬥力很扎實的上升好幾個檔次，不再只能做一些單純的純視覺網頁。
其中摸彩箱讓我印象很深刻，因為前公司尾牙時，有做了一個抽獎app。後來一問之下那個app居然是我們的MIS臨時學的。讓我不禁覺得，這真是個實用的練習，沒準哪天我也會突然被老闆叫去寫一個摸彩箱，讓公司可以進行尾牙抽獎活動。順便為這位十項全能的MIS默哀，工作範圍實在太廣了(笑)
● 印象深刻的物件導向(OOP)設計思維
我前工作是遊戲業的3D美術，不得不說物件導向的思路真的學起來非常的親切。3D軟體的整體架構基本全都是物件導向，每一個功能都是以Obj為中心出發，從 Mental Ray 的 Render Tree 就可以清楚的看出所有東西都是一個一個的物件(或著該說節點?)，這樣的概念。
所以學了物件導向的當下，我才真正理解到為什麼3D軟體是那樣的架構，開始能結合過去的經驗，更加的理解電腦圖學(Computer Graphics)是怎麼一回事。
我一直覺得，國外的遊戲業技術力會這麼強的原因，是因為他們很多美術也都懂點程式，而他們很多程式也都會一點美術。這對他們在3D軟體與遊戲引擎中，開發 Real Time Shader 時能起到很大的幫助。因為遊戲畫面的呈現，單靠程式，或是單靠美術都是做不出來的。唯有兩者良好的合作，才能做出真正好的畫面。
除了畫面渲染技術之外，物件導向的思路真的怎麼看都非常適合拿來寫遊戲，不斷的觸動我的遊戲魂。學著學著我就一直在想，搞不好我以後會跑回去寫遊戲也說不一定。
● 引導式的課題練習與隨時給予支援的助教團隊
這部分在之前學期一的心得也有提過，學期二仍然也保持著一貫風格。
作業不會直接告訴你怎麼寫，更不會給你範例讓你抄程式碼。而是會引導你學會「自行思考」，把自己的所學應用到作業之中。
每一次的作業都讓我寫的很興奮，我只要一有靈感，想追加些甚麼功能，之前課程所學到的東西，都能讓我真的把這些功能給做出來。所以也越寫越開心，越寫越有自信。
每次自行加了很多功能之後，也都很期待助教的回饋。這些都讓我更有動力，朝著更艱難的領域走去。
學期二受到許多助教的幫助，他們讓我更理解專業的開發人員是怎麼思考問題的。也讓我學到很多開發專案必須要注意的事情。讓我可以更早的有職場意識，隨時準備迎接未來會碰到的各種開發需求。
● 參與實習助教，從更高的角度來學習程式設計
最後來說說，貌似是許多程式人夢魘的......「review別人寫的code」
學期一結束後，看到AC的實習助教計畫，思考許久要不要參加。最開始想報名的主要理由，一方面是想說教人勢必自己可以學到更多，另一方面則是單純想賺點外快，回收點學費 (X)
經過面試之後，很幸運的入選。大概在學期二的中旬，開始了實習助教的工作。雖然一開始很戰戰兢兢，深怕自己誤導其他人。但習慣之後，也慢慢的開始放開自我，寫一長串的作業評語。有時候真的很怕被嫌話太多XD
透過實習助教的機會，讓我意識到要客觀的評價別人的code不是一件容易的事。甚至要指出別人的問題，告訴別人要怎樣才能寫得更好，這勢必自己的邏輯也要很清晰才做的到。而且這異常的花時間與腦力。
後來Google了一下關於review的事情。才發現似乎有很多工程師很討厭做這件事，因為太花時間了。還得說明給別人聽為什麼這樣寫不好，這將更加的費時。
所以有很多人會選擇一言不發的直接自己重寫。這導致的結果是，自己累個半死，對方也永遠不會知道為什麼這樣寫不行。
有查到不少矽谷工程師的文章，在分享review這件事情何其重要。
一個很重要的關鍵點在於，當你在職場上變成了別人的前輩，甚至是主管時。很多時候你的工作就不再會是自己下去寫，而都是在review他人的作品，並且給予建議。
這瞬間，角色位置的轉換，讓他們意識到自己不應該只是把程式寫出來交差就好，而是得更深入的思考專案需求，去思考整個團隊。如果一個人寫的code都不符合期待，你卻不花時間告訴他，這將會讓整個團隊都很難互助成長。變成每個人都自己閉門造車的情況。
同時，他們也分享了，其實學習寫程式最快的途徑是去review他人的程式。為了要能精確地指出問題，自己也得要做更深入的學習。而這世界上強者很多，有時看著看著都會發現各種自己從沒想過的思考方式，或是很聰明的寫法。review一個高手寫的程式，可以學到很多平常根本不會意識到的事情。
像是我自己在最後幾周，我就發現到了一個很嚴重的問題。
就是我看code的速度很慢...... 這導致我開始有點忙不過來，不太能兼顧自己的作業，同時花時間去批改別人的作業。這以後勢必會影響我的工作產能，得好好的思考思考，該如何提升速度才行...... (淚)
