作者： HannahLin
来源：medium 究竟，怎麼樣才能算是「資深」工程師？

實作能力

既然是工程師，不管你是上班時做公司專案，還是下班後自己搞 Side Project，最重要的任務就是把腦中的構想透過寫程式實現出來，所以實作的能力絕對是必要的。就像 Linus Torvalds 的名言「Talk is cheap. Show me the code」，光說是沒有用的，只有把程式碼寫出來了，那才算是真正完成了一件事情。

實作能力要到什麼程度才能算是「資深」呢？這也沒有標準答案，但根據我的觀察，資深工程師們的實戰經驗往往非常豐富，只要你的需求不要太過嚴苛（希望系統的可用性有十個 9 之類的XD），幾乎沒有做不出來的東西。

任何 ticket 對他們來說大概都只有「這個簡單弄一下很快就好了」跟「這東西我要花點時間研究一下」兩種，而且他們通常都可以獨立作業，不會突然跑來問你「為什麼我的 npm install 跑不過」、「我沒寫過 Dockerfile 可以教我嗎？」。

說了這麼多，那實作能力要怎麼練起來呢？

關於這個問題，我的想法是要不斷學習新東西，並且真的應用在實戰中。

譬如我原本就很熟悉用 Node.js 寫 Restful API，那下次 Side Project 就可以試試 GraphQL 或是乾脆改用 Rust，雖然第一次寫 Rust 會被編譯器搞得很痛苦（想把電腦砸爛的那種），但寫了就會發現「原來這種地方可能會有 data race！」、「原來非同步不是只有 callback 跟 promise 兩種處理方法」，而這些事情做久了會慢慢提升你的技術深度跟廣度。

有了足夠的技術深度跟廣度之後，既便未來遇到一些沒碰過的東西，也只需要花個五到十分鐘就能看懂他在幹嘛，甚至能猜到底層的技術原理，因此有需求進來時即便不熟悉也可以更有把握的把東西寫出來。

願意花時間做設計

雖然資深工程師很懂怎麼寫程式，但除了寫程式，我認為他們最厲害的地方其實是設計。這邊的「設計」指的不是 UI 上的設計，而是在真正開始動工之前的「系統設計」以及「技術選型」。

我身邊很多資深工程師在工作時並不花太多時間寫扣，因為對他們而言「事前設計」的重要性遠大於「實作」，錯誤的設計一但開始動工了，可能要花費設計階段所需的十倍甚至百倍時間來彌補。

就像我前陣子在幫忙公司的一個專案，那個專案最初是從 2016 開始的，也就是 Python 3.6 發佈那一年，但專案竟然是選擇用已經被官方放棄的 Python 2 來開發，導致後來很多套件都無法更新，整個專案也無法維護，只好重新寫一個版本。

因此在真的開始實作之前，好的資深工程師們會先仔細確認需求、設計資料庫 Schema、思考後端架構等等，等這些大方向都確定下來之後，才是開始寫下第一行程式碼，這種「先確定大方向，再慢慢完成小細節」的工作方式讓我非常欣賞。

要怎麼增強系統設計的能力呢？

系統設計這方面其實我也還算是新手，所以沒辦法給出一個很明確的答案，大家參考參考就好。我認為想要把系統設計做好，除了自己要有一定的技術深度及廣度之外，最重要的就是跟其他人討論，不然很容易受限於自己過去的經驗，而想不到更好的方法。

譬如說我多年前剛開始做 Side Project 時，都是用 AWS EC2 開機器來跑 API server。因為那時不知道有 S3 這種服務可以放靜態檔案，所以 server 收到的資料都是直接放在機器上。而這樣做的代價就是我的服務沒辦法水平擴展，如果效能不夠就只能升級到更好的機器，現在回頭看真的很傻很天真XD。

因此我覺得在對於架構的掌握夠全面之前，盡量還是要多跟別人討論，真的沒人討論的話也可以多看一些文章跟書，像我前陣子看到「系統設計101 — 大型系統的演進」跟「系統設計入門」都很不錯，有很多東西用講的很模糊但圖一看就懂了。

而這些知識都備齊後就是靠實戰累積經驗了，只要每次開發新功能之前都有認真做設計，那必定可以感受到每一種設計在開發速度、部署流程、可擴展性等等各方面的好壞，久而久之設計出來的系統也就會越來越完整。

團隊先於個人

這點是我從其他「真．資深工程師」身上觀察到最令人敬佩的地方，好的資深工程師會去思考怎麼提升整個團隊的效率，而不只是個人的績效。

以寫文件這件事來說，每家公司都會有自己的開發流程、部署流程、AWS 密碼放哪之類的。而我身邊的資深工程師就很樂意把這些東西整理成文件，畢竟如果沒有文件到時也是去問他XD，所以先花點時間寫起來不只省了自己時間、也省整個團隊的時間。

另外，他們也很願意寫自動化測試，當然測試不可能全部都測，但如果能把系統中絕對不能壞的地方用測試保護，那團隊內其他同事在開發時就可以更安心，而且也不會有人假日還要被挖起來修 bug XD。

除了寫文件及測試之外，在技術選型方面，他們也是以整個團隊為優先，認真考量各個技術的效益跟學習曲線。

比方說因為 Docker 很好學，花一個下午就可以學會寫 Dockerfile 了，所以用它來做部署的 CP 值就非常高；但如果說是要用 Rust 來寫 API Server，雖然可以提高效能幫公司省開機器的錢，但一來團隊內的新人要花更多時間才能上手、二來要找到會寫 Rust 的工程師真的不容易，所以顯然不是一個好的方案。

還有什麼要做什麼的嗎？

雖然「以團隊為優先」聽起來很抽象，但其實做起來並不難，只要你抱持著推己及人的心態，在做任何事情的時候都想一下「別人會不會也有相同的困擾？」，然後花點時間幫忙解決，那離資深工程師也就不遠了

總結

要成為資深工程師，絕對不是年資到了或是 Leetcode 刷得夠多就可以。好的資深工程師除了技術能力夠扎實之外，在溝通能力以及心態上也必須足夠成熟（這方面我也還在努力），才有辦法帶領整個團隊一起前進。

以上就是我從自己身邊觀察到的資深工程師，當然資深工程師還有很多種樣子，而且他們有些還會有自己的特異功能（特別會通靈、隔空解 bug 之類的XD），因此大家有空也可以多觀察身邊的前輩們到底厲害在哪裡，也許能從他們身上學到不少東西哦～