其實中途因為有一篇被吃掉導致原本想放棄這三十天的挑戰，
被某個前輩的一句話給救回來。

不用去學那些有的沒的，在這領域待久了自然就會進步了。

其實這只是前輩一句無意義的話，不過真的是讓當時的我茅塞頓開。
在職場中待久了，慢慢的會被deadline(期限)文化影響。
總想著在期限內完成甚麼事情。

但是不論在學習或是開發中，常常會有意外發生。
當期限逾期了就選擇放棄那進度就永遠停在那了。
而選擇繼續走下去就還會有前進的可能。

成為資深工程師的這檔事

近幾年來同儕們也都漸漸地轉為資深工程師了，
在我們相互分享變成資深工程師的過程大概只有這麼一個共同點-公司認同你
沒錯!! 就只要公司說你是你就是了，事情就是這麼簡單。

但這時有個問題，我們是否要做一個受到認同的資深工程師?
若答案是肯定的，那勢必需要具備其他工程師不具備的能力。
最簡單的方式就是在你的技能庫中加入設計模式。
即便你並不知道何時要用哪個設計模式，
當你跟別人溝通時能脫口而談，甚至能實作出，在大多數環境下已經可說是人上人的存在了。(誇示了)

職涯的平凡之路

在當工程師的成長的路上很多人都卡在一個迷思，
就是不斷地去摸摸那些大神們幫忙整理的常見前後端語言及工具。
雖然這對我們的個人能力會有所提升，
但這通常只是讓我們從一個工程師變成一個會比較多東西的工程師而已。

隨著我們踏入職場後的年資慢慢地提升，對於專案的理解及看待的角度也要慢慢地改變。
在這系列文的最後也跟大家分享一下不同時期看待專案的角度。

1. 剛出社會成為工程師時期:
   這時候通常沒有實務經驗。在這個時期最重要的是不斷嘗試不同的技術。
   在這時期會接收到大量的新知，各式不同的語言甚至工具的協作。
   可以在這時候多去了解這些東西看看技術文件、或是做一些Side Project。
   趁著剛開始練手的時候去了解他們的運作原理，熟悉各種語言和工具。
   這會對往後除錯(Debug)或是撰寫的速度，有很大的幫助。
   (只要還是工程師，都會做這階段在做的事情，只是時間花費的比例不同而已)

2. 熟悉一門語言時期:
   通常在公司裏面用某個語言做一個半年到一年的專案就算是熟悉一門語言了。
   這個時期大概是工程師中最灰暗的時期，會發現已經沒有甚麼新的技術好學，
   好像已經無所不能，要自己開發也只能說通通不能。
   這時候很多認真的工程師就去學習其他的語言或是工具，開啟協槓工程師人生。
   當然這樣做也是有好處，不過漫無目的的學習比較容易疲乏，
   所以在這階段建議學習設計模式，並在程式內加入設計模式，
   不論使用FP、OOP的開發都有各自的設計模式，
   多去了解這些設計模式，讓我們對問題具備分類及解決的能力。

這是一個常常被忽略的時期，很多工程師學了一堆技術後就直接躍升為軟體設計師。
導致容易發生系統結構鬆散常常開發出一堆Bug的系統。
主要的問題對於一個新上手的設計師對於實際開發上細部的構思不夠全面，
導致會遇到一些程式上不太好的Code Smell(程式碼異味)。
(這是很多工程師忽略的環節，也是最容易凸顯出不同格局的時期)

3. 系統、軟體設計時期
   這時通常已經有個三五年的工作經驗。
   能堅持到這還繼續有自主學習能力的人，不論職位是甚麼基本上在公司內都算是人上人了。
   (不要懷疑，堅持努力成長三五年，絕對有讓人意想不到的差距)
   在這時期有兩個需要努力的目標，在專業能力上，
   歸納常用的設計模式的應用場景和了解軟體設計架構。
   因為編制的問題，很多純軟的公司可能已經不會再去細分系統架構師
   跟軟體設計師了。所以這邊就直接把兩個連在一起說吧。
   當我們是負責規劃設計的人，
   對於細節的部份應該要歸納過往的經驗，不再去注重設計模式的細節，
   而是統整出應用的時機。這會讓我們在設計時減少腦袋瓜的運作，
   將細節下放給開發的人(雖然也可能是自己)。
   至於整體系統架構這部份已經算是技術層面的高空砲。
   各種流派百家爭鳴，基本上就是多認識一些常見的架構
   (分層式架構、MVC架構、微服務架構...等)。

另外一部分在軟實力上也是個人的誠心建議，
3~5年的年資說老不老，說小不小，上有主管、下有新人。
已經不再是當初的初生之犢，得開始學會如何好好講話。
當你走到技術的顛峰後，能不能好好生存下去，真就靠那張嘴了。
懂得說話的藝術，會讓職場的路更加平順。

4. 專案管理時期
   這個大概是不進入管理階級的最終型態。
   在這個時期並不一定是我們自己在管理專案，
   而是要知道整個專案如何運作，以及進度推進的方式。
   了解各種專案推進的方式 TDD(測試驅動)、ATDD(驗收測試驅動)、BDD(行為驅動)...等。
   以及專案運作模式Waterfall(瀑布式開發)、Agile Methodology(敏捷式開發)...等。
   雖然不是所有的人都會想進入這個時期，但是了解整個專案的運作方式，
   即便不在其位，也能幫助團隊提升開發效率。

結語

在職涯每個階段的成長中還有更多的細節可以去摸索，
這邊只是希望透過分享在每個階段不同的格局思想。
讓各位咱們這些工程師在學習的路上不迷茫。

也很感謝那些關注我的小夥伴們，
你們的支持真的是我繼續撰寫的原動力。
最後我也會繼續找時間完善前面的內容。
做一個完美的Ending。