Welcome to GSS
工作內容
工作詳述
最開始我加入了ID小組，最開始幫忙修改一些客製的小Bug，接著加入了PD小組，這時才有一種自己開始上班的感覺，負責將舊有的用VB寫的程式，依原邏輯翻成用C#寫的MVC架構的程式，本以為是個簡單的工作，實際上做的事看起來也不算複雜，而這整件事卻因為我不好的Coding習慣變得很複雜。
MVC的view，而這件事，通常應該是最簡單的一件事，不過卻遇到問題，因為公司用的頁面上都是依照kendo UI這個Framework，再進行包裝過的控制項，所以在使用上會有一些不知道功能是什麼的屬性，有一些在畫面上需要一些方法才會實際顯示出來，導致我會不去在意他，但是這樣，就會多了一些實際上不必要的屬性
呈現在畫面上的錯誤訊息，要用讓人看的懂的方式去呈現，否則沒有意義。在翻新程式時有遇到舊程式因為是用把錯誤訊息用寫入記錄檔的方式去呈現，而換成新程式的時候改成直接用grid顯示在畫面上，而舊的紀錄檔中錯誤訊息用的是開發者看的懂的方式去搭建的，現在換成顯示在畫面上就要換呈使用者可以看到的方式，方便使用者知道問題在哪裡，因為這個錯誤訊息是使用上的問題，而不是系統出錯。
在sql上進行權控這件事，把帳號分級，不同等級的使用者可以看到的資料會不相同。因為同樣一個系統，會有各式各樣層級不同的人使用，而有些功能不會開放給一般員工使用，或是他們可以看到的資料就是與自己相關的內容，否則會有各式各樣資安上的疑慮。
盡可能的不要跑迴圈，因為你無法預期撈回來的資料到底有多大，實在不行一定要跑迴圈的時候，要先用LINQ語法將資料排序後再做使用，並且在迴圈達到預期想要的結果時就讓它終止，盡可能的去做到這件事才可以有更好的效能，而不是像在學校寫程式時，想怎麼做就怎麼做。
.
學習
GIT
雖然還未加入公司時，也多多少少知道有git這樣一個東西的存在，但在以前我只把它當作是一個雲端硬碟一樣的東西，而在加入公司後真正知道這樣一個東西的重要性，而這也是我這近半年實習下來學習到的很重要的東西，接下來我要講述我到底學到了什麼。
1.使用的流程
在公司時會利用小烏龜TortoiseGit這個Git Gui去進行操作，而所要做的第一件事就是將專案從git上clone下來，然後按照規定的方式去建立新的branch而不是直接在master上開始做程式更動。
因為假如在master上直接做更動，改壞掉之後，會很麻煩，接著做完更動後，要按照格式寫下commit的內容，而不是隨便寫，因為別人也會看你的commit內容，commit的內容是未來檢察哪裡有問題最重要的紀錄，除此之外，也要確定文件內容，不要將不必要的檔案commit進branch裡。否則，又要再做一次處理，在把commit的內容push上git之前，要做的動作是先pull master的版本，先將衝突解決，再push進git，最後發起merge request，等待擁有merge權限的人經過檢查後，假如沒有問題就merge進master，在虛擬機上進行測試。
2.如何解決衝突
在merge進master後，就到了QA做測試的時間了，假如有出現問題，就會需要再次處理程式，直到預想的到的結果都沒有問題。
而這樣子的開發流程，我覺得是我在離開公司後也可以繼續使用的一套方式，簡單，條理化，而不是像無頭蒼蠅一樣想如何使用GIT都可以，假如，沒有像這樣的開發流程，還不如不使用GIT，使用GIT反而會使情況變得更為複雜。
問問題的方式
來到這間公司後，這件事變的格外重要，因為我幫忙翻譯的程式裡含有大量公司包好的method，而這樣勢必就需要詢問PG的前輩，如何使用這些method，而我也是在經過幾個月後才終於發現問問題的方法。
先試著總結出自己的問題，而不是遇到跑不過的東西，就去問問題，否則會照成別人的困擾，也不一定可以得到真正正確的資訊。
不過，老實說，我覺得在這件事上我需要更多的學習，因為就算是現在，我也無法保證自己可以提出絕對正確的問題，只能盡可能的有條理的去描述我的問題，這裡也要感謝同事的幫助，他們真的是不厭其煩的回答我各式各樣的蠢問題，可以清晰描述問題，這件事在我下半年的實習過程中應該還會是一個挑戰。
表達自己的方法
我不是一個非常善於表達自己的人，也許在同輩小組討論中，因為沒有人願意出頭的情況下，我會試著去盡我最大的努力，去分配工作，去做那個所謂的組長，但其實我不是善於這樣做的人。
然後這件事，在實習時，就被放大了，因為我不是一個擅長表達自己的人，而在工作上這樣的情況是十分吃虧的，因為開發軟體的工作講求效率，沒有人會等你扭捏完才開始講話。
對於這件事，我做的努力就是觀察，觀察別人在CodeReview時，會說那些話，會用什麼樣的方式去告訴其他人，自己正在做的功能是什麼，遇到的問題是什麼，闡述這些的時候，大家都會試著用不是太嚴肅的語氣去講，假如用太過嚴肅的語氣去講這些內容，整個空間的氣氛就會變的有點凝固，而且大家的語氣也不會是輕鬆愉快的。
經過這段時間的鍛鍊後，我漸漸開始學會表達自己，盡可能用最清楚的方式去講述自己正在翻譯的功能，雖然在態度上可能還是稍顯僵硬，不過，可能是因為前輩們都很友善的原因，近幾次的CodeReview我已經漸漸開始覺得，自己是部門的一份子了，漸漸開始大膽起來，也能更好的表達清楚自己的意思。
紀錄歷程的重要性
最後就是，紀錄歷程的重要性，每一次問完問題後，我都會試著把issue記錄下來，否則遇到相同的問題再去問一次，實在是一件很沒效率，並且很打擾別人的行為。
並且，可能是因為一週只上三天班的原因，每次都會有一個非常不舒適的銜接感，所以每當週五時，我都會寫下一個note去記錄說，這周做了什麼，下周要從哪裡開始。
而這樣的好處是，遇到問題，我可以先翻找以前的紀錄，而不是直接詢問別人，並且這些紀錄也不斷的提醒我，相同的問題不要再錯了，這些紀錄很大部分來自於SA檢查我的merge request時給的反饋，真的很感謝她不厭其煩的給出建議，做出提醒，這真的很幫助我在Coding的習慣上有更好的提高。
這樣的習慣，未來應該也會幫助我在學習或著工作上，可以有更好的管理自己歷程的方式，我相信這個習慣，會是未來人生不可或缺的能力之一。
自我評估及感想
1月十號左右，懵懂無知的我作為一名實習生，來到了叡揚資訊股份有限公司進行學習，剛加入時,為期兩周的新人訓練，因為卡到過年，所以硬生生的拖了一個月。
而在這段時間內學習到的東西，就是MVC架構，以及習慣的養成,。這段時間做了一個簡易的圖書管理系統，只有簡單的增刪改查的功能。
下專案以後,先是在ID小組待了一段時間,感覺的出來ID有很多很難的問題要處理,所以在給我issue的時候只能挑簡單的給我,不過,在這裡我第一次感受到SQL會有效能上的疑慮這件事,因為以前不管怎麼寫,資料筆數都不夠大,不會有這個問題。
接著加入了PD小組，開始學習翻新功能的工作，在這裡，每周一次的CodeReview，以及前輩們各式各樣的指點，都讓我收益頗豐。
不過，這段時間，我也感受到上班的辛苦，而且是非常明顯的感覺到，每天六點就要起床，六點半就要從家裡出發前往在台北的公司，然後上班時間是從早上九點，一直到至少下午六點，至於是否要花更多時間留在公司，那就是個人的選擇了。
除此之外，其實整個部門的氣氛是非常活絡的，在鄰近下班時間，大家會開始聊天，而不是一直埋頭苦幹，死氣沉沉，適時的放鬆也是工作上十分重要的一環。
每個月一次的實習生月會，可以聽到別的實習生的分享，了解不一樣的新知識，新技術，我覺得這是一件蠻重要的事，因為除了自己處理的工作內容之外，了解別人的工作內容也是蠻有趣的一件事。
不過，這半年來的實習，我覺得最重要的是理解自己適合這樣的工作嗎?假如以後也要做工程師需要什麼樣的能力?
我的結論是，我可能沒有身任一名工程師最重要的能力，快速學習，我的學習方式一直以來都是經過經驗累積的方式進行學習，而這樣的學習方式對於要不斷面對新技術的工程師，顯然是不夠迅速的，除此之外，我覺得能夠長時間不斷的面對程式碼，也是一種很厲害的能力，長時間專注在程式碼這件事，我覺得對於我來說很困難。
不過，顯然對於選擇了實習這件事情感到後悔是沒有意義的，所以在下半年我會嘗試繼續努力學習，繼續確認自己未來會不會成為一名工程師這件事。
對於這近半年的實習，我對自己的評估是，能力不足，對於發問這件事的積極性不夠高，可能是因為害怕問錯問題，不過這也是我有在盡量改善的部分，這在前面也有提到，不過，說白了，我對自己這段時間的表現，不是很滿意，能做的事就是繼續努力改進，希望在明年結束時，可以給自己一個完美的答卷吧。