11/12

後端工程師魔鬼訓練

繼上週，我的同事幫我擬了一份短期後端工程魔鬼訓練

企圖讓我從不折不扣的碼農，向上點工程師的技能樹

好讓我在每天都可以有一點小成果

約莫三週後，就可以有大幅的成長

畢竟被同事譽為被放牛吃草快兩個月

根據擬定的菜單，我們上週已經將下列清單劃除的地方完成

熱身指南

1. 學習Debug Tool, 並利用Debug工具追蹤程式流程。

2. 學習 Design Pattern。 先專注於Template Method Pattern。能舉實例說明，如何演化一段程式為 Template Method Pattern

3. 找一個專案程式為範本，試著還原最起始狀態，運用 Template Method Pattern 來演化出一套 Framework

初階工程師技能

1. debug tool 能使用 debug tool 追蹤問題

2. 開始接觸與專案相關的 Design Pattern

3. 會執行 Unit Testing，並掌過 Arrange, Act, Assert 的 3A 開發節奏

4. 學習 refactoring 並能識別 bad smell

接下來這一週，週一跟週二的進度

我自己訂定為

1. 拍攝上週進度更好的DEMO影片

2. 了解並嘗試實作紅字部分

雖然目前先不要想太多，但難免希望這週尾端能開始接觸Unit Test

鷹架理論

11/13

週一週二過完了

我順利的將紅字部分完成，雖然熱身指南的第三項我大約完成了1/3(因為我把專案的整體架構濃縮成較基礎)，但我還是順利完成了我給自己定下的目標

熱身指南

1. 學習Debug Tool, 並利用Debug工具追蹤程式流程。

2. 學習 Design Pattern。 先專注於Template Method Pattern。能舉實例說明，如何演化一段程式為 Template Method Pattern

3. 找一個專案程式為範本，試著還原最起始狀態，運用 Template Method Pattern 來演化出一套 Framework

初階工程師技能

1. debug tool 能使用 debug tool 追蹤問題

2. 開始接觸與專案相關的 Design Pattern

3. 會執行 Unit Testing，並掌過 Arrange, Act, Assert 的 3A 開發節奏

4. 學習 refactoring 並能識別 bad smell

明天應該能試著了解Unit Test以及試著將熱身的第三步驟實做得更淋漓盡致

早上同事又將我的新魔鬼訓練變更任務清單

但變更的部分在於專案流程學習

專案流程學習

在各個環節提問，或找相關人員對他陳述一次理解，以確保接收到的訊息是一致的 旁聽時，練習任務預估，在心中比較與其他人的差異。 能將PM分割的任務，轉成對應的 Issue 並完成初步的設計。(能開始實作更好)

實作專案 ! !

早上詢問了同事幾個問題

也讓我這小菜鳥有了打拼的動力

這個問題就是

工程師能做到老嗎？

在進入公司後，心情複雜了好幾週

起初看了一些文章跟新聞得到的消息是

工程師不能做到老，且面臨中年危機

於是讓我這個剛進公司的小菜鳥，開始在找我人生的第二條路，以免中年失業(會不會擔心得太快了XD)

凡事都要多準備

但同事丟了一個連結給我

https://www.ptt.cc/bbs/Soft_Job/M.1270487051.A.563.html

其實我自己本身就提倡要打破傳統跟突破社會框架

結果反而自己被侷限在這種思維中

反被同事虧了一把

以你之前那種土炮模式寫程式

你大概做一兩年就整組壞掉了吧

沒錯依照我以前寫程式的方法跟模式

也就是寫了一堆很亂，毫無架構性，且Bug一堆的程式

接著就是修Bug修到死，難怪我一直修一直修，花了大把青春大把時間埋沒在寫程式

然後還找不到任何成就感

所以才剛進公司我就很茫然，甚至我還懷疑自己真的這輩子都要這樣過？

你能把這麼有趣的工作，做得這麼無趣，也是蠻厲害的

被同事砲了QQ

撰寫程式學問大不同

軟體開發也許是一門看似獨立的理科學問

但實際運用於軟體開發內的方法與規則，卻能運用至各個領域

寫程式在我母校的資管系大學生眼中是個無趣又無聊的事情

雖然不是很想這樣說我的指導教授XD, 但我認為許多課綱確實把寫程式教的很無趣

我本身以後端工程師的角色切入這個社會

剛進公司時，我認為我缺的就是技術，就是個技術上菜鳥

我無法理解那些口口聲聲説程式只是工具的前輩們

因為在我這個階段，會的程式語言，會使用到的工具攸關到我找不找得到工作

事實上，工程師確實偉大

公司的各個部門都很偉大，因為在團隊合作中，無論是哪個部門，彼此都需要互相的專業領域來合作達成公司營運

但對於團隊合作以及整體公司營運中，我們工程師為技術部門

我們提供的就是技術的工作產出

技術又包含很多種層面

換句話說，會程式語言只是基本

因為對於公司我們能提供的就是技術/想法

• 如何將好的技術研發出來

• 如何管理"技術"們

• 如何有效率撰寫技術

這還不包含

• 如何與其他部門溝通

• 如何將成果展現與良好的管理

• 以及前輩如何帶領後輩

• 其他種種工作/社會複雜的知識

同事的點一下

我想提出兩個方法

真的覺得不愧是在職場打滾許久的前輩QQ

懂程式懂心理學，又懂管理學，我的天。。

**Best Practice **

從Wiki來解釋

**最佳實踐**（best practice）是一個管理學概念，認為存在某種技術、方法、過程、活動或機制可以使生產或管理實踐的結果達到最優，並減少出錯的可能性。

他可以被運用到許多不同的領域

被運用在軟體開發內，則是能夠有方法的使寫程式的流程更順暢及寫出更少Bug跟產出更優質的程式碼

在菜鳥時期或許還無法，但隨著經歷夠多的練習跟經驗，我相信工程師的工作可以做到老，只不過到之後的時期工程師可能就不會僅僅是寫Code，除了將提供技術的流程減少出錯並達到更優質外，還需學習到其他軟體開發以外的相關知識

Test Case

聽同事說，很少有工程師會寫Test Case

而在前幾篇我們有提到在敏捷方法中的TDD

就是先寫Test Case 測試案例，將有可能會遇到的問題跟錯誤還有預期的結果先寫出，再針對案例寫程式，重構程式，接著反覆進行

目的是希望不要在把所有的程式碼都寫完了，才進行測試，錯一堆又要改

也可以在先撰寫測試案例時，引領程式碼會需要有哪些功能，使設計框架或撰寫程式碼時能夠更專注地環繞在功能上

這部分若說運用到其他領域的話，其實也就是運用其概念來實行

也就是說在實行某一特定技術時，可能先列出會破壞此一技術的元素

然後再將技術做好，做測試

若被破壞了，再將技術做改變，直到能承受破壞而不被影響

接著反覆做這些動作，直到技術變得完美

(這是我個人認為測試案例除了軟體開發外，還能運用到其他領域(像是工業用品))

從我以前到現在從來只有在教科書上看過TDD的運用

我之前寫Code到現在從來沒有使用

到現在終於要使用啦!!

期待之後運用後，在記錄下來

且隨著自己待在公司工作接觸到更多社會上的知識外，還接觸更多厲害的人

希望能夠像個小小記者，將他們的偉大知識與成就記錄下來