趁跑單元測試的時間, 來發篇沈睡在草稿夾裡許久的文章

前陣子跟同事聊天，驚覺自己貌似是那個後端新手的幸運兒，因為誠懇的態度感動了前主管兼面試官，讓本菜鳥得以進入社會的殿堂發展自己的後端長才

想想當初只不過第一次面試，當然要客套話說盡，沒想到居然無意之間被選上qqq，大感動！

哪這麼偉大，據科普顯示，才不會有人願意使用職場新手擔任後端工程師，因為一個搞不好，系統就會炸掉qq

在這個連假的前一天，大人都不在的時間，趁Q1快結束，來實現我作為後端工程師的OKRs 之一 qq

這一天，拜前幾天因繁忙的工作而矛起來想一步登天的動力所致，加上感染連假前一天的氣氛，今天特別想發懶

由於敝人為菜鳥階級，每個發的 pr 的被資深的大大擋好擋滿，並留下滿滿待修改的回饋

帶著絕望的心情上網估狗了個關鍵字 程式趕著上線 品質不一 ，並碰巧找到了與此篇文有著相同觀點的文章，碁峰出版的某本書

在 序 中提及作者於萌新時代僅迅速敲完程式完成專案為首要，隨著經驗的累積了解最重要的並非迅速完成程式碼，而需更重於 測試 Test, 程式碼 Review 及 重構 Recactor，也是我在 後端小菜鳥 系列 新手工程師指南發的幾篇文章主題。

而我也正在經歷此階段。

對於初入戰場的新手們，光是完成前輩口中說的工作，就需要渾身解數，想盡辦法來達成工作。尤其再加上時間的催化，簡直讓完成的程式碼們慘不忍睹。

由於對程式碼不熟悉，以及學校沒教的技能，入職場才會學習到那些學校不會教你的事，隨著踏錯好幾次冤望路而慢慢彌補一塊一塊坑坑疤疤的漏洞 (一把鼻涕一把眼淚)

各位別忘了這門領域叫做 程式設計 ，哪是迅速敲敲打打程式就能達成的領域 qq ，把 設計 兩個字擺哪呢？

幸運的是，剛進公司有資深的mentor引導，我才進公司第三個月就接觸到了上述提及的三項重要技能。

迅速達標的心態

先撇開資深工程師可以顧好品質又順利迅速達標，在研究所時間，透過網路上各種消息便能得知，在軟體業中常接到一個新專案，客戶趕著需要作品，就需要迅速完成結案。

別說是資深工程師了，若是讓新手嘗試，那便是為求 迅速 而埋頭敲敲敲敲程式，最後產生漏洞百出品質差的作品

反正客戶也不懂程式碼，客戶也不會去看程式碼，亂寫他們也不知道，只要能動就好

這是我研究所的指導教授跟我說的， 只要能動就好

不！ 這怎麼跟我遇到的情況不同，難不成我技能樹點錯 (?)

當你結束專案，把程式碼交到對方客戶手上的那一刻，你已經不用負責任去修改接下來會發生的任何錯誤了

接著由於以上的狀況，公司為求接大量的專案並迅速完成來賺錢時，甚至會訓練新來的工程師，只要求會初階的程式技能，並利用套版抄襲先前的專案，複製先前的程式碼，換湯不換藥，稍做修改後又成為新的商品賣出交差了事

還有另外一種現象，新手們出入戰場，透過各種專案摩拳擦掌，在沒有任何資深工程師引導的狀況下，讓品質差的程式碼日積月累，造成後續修改/重構工作十分困難，也造就爛攤子留給下個新進員工修改的窘境

當然我研究所的指導教授就是這樣接案賺錢的，造就我這個萌新的三觀毀壞一次，直到進了現在的公司遇到了現在的mentor才發現，原來事情不是這麼簡單

這是一個導正三觀，並走對路的好情況，但卻讓我沒辦法用抄抄程式碼, 無腦複製複製 與 呆滯 來交差我每一個專案目標

可惡，一定是我當初選門脈選錯了，才會走錯路

而我，由於正開發公司的主要產品，程式能力底子弱加上不懂那些 軟體工程師的內功與技能，在欲迅速達標的每次Scrum週期中，每每只要我埋頭苦幹的敲打程式，往往能趕在截止前完成任務。

但程式碼會變得品質很差，難以閱讀及Debug。

不過通常不是軟體工程師的偉人完全不會注重品質，能動能賣就好，這也造就了不少表面上用起來順暢能執行的程式，骨子裡卻雜草叢生

品質的提升：重構, 測試 與 Review

初入職場的起始，我的腦袋每天都被大量的新知埋沒
做夢都會夢到我在寫程式，for迴圈在我的腦袋內無限奔跑
原先我安慰自己隨著時間變化，等到程式語法熟了，就不會腦袋發熱
沒想到翻過了這個山頂，還有下一座山頂，永遠都有無限的電腦新知等著您

原先在許多工程師生涯中也許工作一陣子才會遇見的 品質三部曲 (對不起我亂取的)，我在第一份工作第三個月時經由mentor引領接觸到如何提升程式碼的品質三部曲: 重構, 測試 與 Review

在沒有品質三部曲的輔助下，程式碼將會越長越難看

還記得先前為了在周會分享重構，我寫了一篇大致介紹重構的文章

延伸閱讀： [後端小菜鳥]初階工程師魔鬼訓練(5) - 淺談重構Refactoring

何謂重構？ 為何重構？

「重構」是在不影響程式輸出/ 結果的前提下，整理程式碼，換個方式實作，讓其可讀性提高及提升效能

重構使改進軟體設計
重構使軟體更易被理解
重構助你找到臭蟲
重構助你提高編成速度

不得不說，我每次都重構我的程式，讓許多為使用到，可縮減的程式碼變得精簡好讀，每每重構都能刪除一堆先前很繁雜的程式碼

也能透過重構程式，讓臭蟲全部裸露XD

搭配 Review Code，可以將一些當初搭配專案時程迅速開發所造成的缺失，趕緊整理程式碼與刪除些未使用, 不輕易被閱讀的問題解決。

我並不排斥重構，相反我很期待它，因為重構就像是在幫原先努力向前衝刺不顧一切亂扔東西的自己善後，為迅速施工的房間，好好的做清掃與整理，讓他們變得整潔又乾淨。

但顯然有點不喜歡 Review，因為真要 Review 一定有一堆程式可被修改，會讓新手的我有一種永遠改不完的錯覺，進而大失士氣。

Review 程式碼是好的，有的時候我也期待被資深的工程師 Review程式碼，每一個來自他們的評論都是成長的好機會。

但不得不說，我確實很討厭，在趕專案的週期時，所有的pr 被壓著不過的急湊感，這也是我發這篇文章的主要原因。

最後想來說的是單元測試

最近讓我覺得不太對勁的是，寫單元測試幾乎花掉我超過一半的時間

當我正在趕專案時程時，必須迅速完成任務時，往往是隨意思考實作方法，覺得可行後，馬上就動工完成(不過在這過程，只要實作遇到的困難與原先隨意思考認為可行的方法相駁，那就得來來回回做更改，甚至還有可能模糊原先的焦點)。十分急躁，想快速完成這個任務，往下個任務邁進。

此時我很討厭寫單元測試，因為常常是我的實作完成了，但卡在我不會做假設資料，不會假設的方法來驗證我的實作是對的。

但這也意味著你得硬性讓你的程式過測試，讓你的程式有品質。

不過，最近我對於 單元測試 有大突破，我開始貫徹 測試驅動開發 Test-driven development，懂得利用單元測試來假設場景去預想程式會怎麼實作，長什麼樣子，會怎麼被執行。並撰寫有可能會發生的例外來做測試。

雖然在實作中單元測試的撰寫還是花費掉我一半以上的時間，但由於悟道悟通，我已能透過撰寫單元測試來假定完成的實作樣貌，並在真正實作專案程式時，很迅速地就能夠將實作完成。

後語：顯然在目前我在跑Scurm 專案時，面臨資深工程師離職所留下的 double 工作量，使用渾身解術敲敲敲，趕在時程結束前完成

但卻因為急躁及忙著完成工作忽略了品質，在被Review 時，pr 被資深的大人擋好擋滿，才造就我現在發文的窘境，哈哈