明年就是我的開發者生涯的第十個年頭。整整十年！我有三分之二的時間都用在了 Web 開發上。在孩童時代，當其他小孩還在學習樂器或芭蕾舞的時候，我在自己的臥室里用代碼編織了一個神奇的世界。為了給這十年來一個總結，我想分享一下我在過去的十年當中作為一名開發者的心路歷程。

對于現今的初級開發者來說，或許他們會在這篇文章里找到一些能夠引起他們共鳴的東西，或者讓他們深受鼓舞的東西。對于現今的高級開發者來說，或許他們也有一些有趣的故事可以分享，因為他們都是過來人。

1. 我是高級開發者

我在 19 歲的時候開始應聘我的第一份開發工作，當時的那個職位叫作“Student Webmaster”。這個職位很有意思，因為如果你拿到這個職位，就變成了“學生”和“大師”的結合體。不過現在的人更希望成為“工程師”，因為這個頭銜聽起來似乎更有發燒友的味道。我當時的工作是負責 PHP 和 MySQL 方面的開發，維護 Drupal 網站，以及開發一些內部工具。

因為在孩童時代就開始寫代碼，并且我很肯定它們可以作為正式的經驗，所以當被問及我有幾年 PHP 經驗時，我非常自信地回答道：”三到四年“！

我當時覺得我對 SQL 應該懂得挺多了，因為我都會用外連接了。

在當時，三到四年的經驗意味著我可以拿到比較可觀的薪水了。

五年之后，我開始了最近的這份工作。即使是到了這個時候，我的代碼都沒有給別人評審過。在部署代碼的時候，我直接從 Git 上拉取代碼，然后通過 SSH 部署到服務器上。我敢肯定我幾乎沒有提交過 PR。不過不要誤會，其實我在頭兩份工作中學到了很多有用的東西，只是我從來沒有真正地和其他開發者一起開發過同一個代碼庫。我就是這樣去申請了”高級前端開發“的職位，并拿到了 offer。

就這樣，我成了一名 24 歲的高級開發者。

我的意思是，如果我撐不起這個頭銜，他們也不會給我這個職位的，對吧？我很確信的是，我之所以能夠拿到這個職位，是因為我過去的那些令人印象深刻的經歷。我感覺自己達到了職業生涯的巔峰，我是公司里最年輕的開發者。

我最終學到了什么

每個時期的經驗都是不一樣的。孩童時期的編碼經歷、學生時期的編碼經歷、CS 研究員時期的編碼經歷，以及在成長型初創公司時期的編碼經歷，它們對我來說都是無價之寶。但各個時期的經歷都是不一樣的。在職業生涯早期，如果你加入了一個優秀的團隊，那么在一年內學到的東西要比自己獨立工作五年多十倍。如果你的代碼沒有拿給別人評審，就不會成長得那么快。

所以，導師很重要。加入團隊比暫時多賺點錢要重要得多。如果有可能，不要接受那種獨立工作的初級職位。在選擇第一份工作時，不要只為了錢，加入好團隊才是真正有價值的。

職位頭銜什么的其實都是浮云。想象一下 5 人團隊的 CTO 和 50 人團隊或者 500 人團隊的 CTO，雖然頭銜一樣，但它們所要求的工作技能卻是完全不同的。所以，我也不會因為被安了“高級開發者”的頭銜而變成高級工程師。而且頭銜具有“迷惑性”，同樣的職位在不同的公司之間也不具備嚴格的可比性。

2. 每個人都會寫測試代碼

我的職業生涯的前半部分主要從事學術方面的工作。具體地說，有三年半時間花在了一個由公共基金支持的項目上，然后一年半是在大學里。我可以告訴你：學術界的編程與業界的編程其實完全不一樣。

你的大部分時間并不是在開發應用程序，而是在寫算法或者解析數據集。如果湊巧你是在開發應用程序，那么它很可能也只是個公共項目——要么是免費的，要么是開源的。免費的項目意味著你不一定會全力以赴把它做到完美。

畢竟，天下沒有免費的午餐。

后來，我帶著很多期望離開了學術界。

我期望能夠在業界看到我想看到的東西，比如自動化部署、PR 和代碼評審，以及高質量的代碼！我堅信業界的每個開發者都會寫測試代碼。

但是，在我加入第一家初創公司的那一天，居然沒有看到任何測試代碼。前端沒有，后端也沒有，什么測試代碼都沒有。

更糟糕的是，沒有測試代碼也就算了，居然沒有人認為缺少測試代碼是個問題！帶著一點點的天真，我就當是他們不知道如何為 AngularJS 編寫測試代碼吧。如果我教他們怎么寫測試代碼，或許這個問題就解決了吧。但我錯了！幾年之后，我們在添加自動化測試代碼方面有了長足的進步，但與我最初想象的并不一樣！

他們之前不寫測試代碼并不是因為不知道該怎么寫，而是他們體會不到沒有測試代碼的痛苦，或者不堪忍受維護遺留測試代碼給他們帶來的痛苦。

我最終學到了什么

很多公司或者初創企業壓根就沒有測試代碼，即使有，數量也很少。為了讓產品盡快上市，或者為了生存，很多初創公司忽略了早期的測試。即使是那些看起來挺不錯、贊助過開發者大會或開源項目的公司，它們的一些項目也都是只包含少量測試的大單體。

沒有一家公司的技術棧是完美的。每一家公司都有自己的問題，都逃不過技術債務，關鍵在于他們做了哪些事情來解決這些問題。

如果你在某些問題上缺乏實際經驗，但又固執己見，這樣就顯得有點傲慢了。我給人的印象是一個無所不知的人，并堅持一定要寫測試代碼，但我在這方面其實也沒有大量的經驗可言。堅持原則固然重要，但也要試著開放心態，并真正從別人的經驗和角度來看待問題。

3. 我們比別人落后太多

這個與上一個話題有點關系。我們公司沒有人寫單元測試代碼，但是其他公司的人會寫的，對嗎？

我讀過很多博文，在 YouTube 上看過很多大會演講的視頻。好像他們每個人都能做出非常復雜且質量很高的應用程序，不僅性能好，還非常有趣。而我呢，能夠趕在截止日期之前把能用的東西拼湊在一起，并讓它們運行起來就算不錯了。

基本上，我對這些公司充滿了崇拜之情，但同時又對自己的公司和項目落于人后而感到失望。

我最終學到了什么

很多大會演講只涉及概念驗證，并不是真實的案例。如果你在某某技術大會上看到某一項很特別的技術，那并不意味著他們公司一定會在日常開發中使用這項技術。通常，演講者所使用的演示 App 并非真實的案例，所以要注意區分它們。

處理遺留代碼是很正常的事情。通常，人們會理所當然地認為別人的公司不需要處理遺留代碼。但在技術大會上與那些大公司的人交流過之后，我發現，他們和我們的處境是一樣的。有遺留代碼是很正常的，相比從頭開發 App，學會如何處理好遺留代碼將會讓你學到更多的東西，因為你會接觸到更多你之前沒有接觸過的概念。

4. 代碼質量最重要

在以前，我對代碼評審的要求是很嚴格的。

至少，我對代碼風格是十分挑剔的。縮進、格式化、命名——你最好要做得和我一模一樣。代碼評審不留下任何評論的幾率跟中彩票的幾率一樣低。

想象一下，一個 PR 里有我的 50 多個評論，都是因為缺少分號！

因為我有一雙老鷹似的眼睛，不會漏掉任何一個分號！

我最終學到了什么

做到足夠好就可以了。代碼質量“好”到一定程度，它給我們帶來的收益是遞減的。代碼不需要完美，只要維護起來不像是一場災難就可以了。通常情況下，有點啰嗦的代碼讀起來反而更容易理解。而且，“好代碼”與“它看起來就像是我寫出來的代碼”是兩碼事。

看清整體架構比對細節吹毛求疵更重要。少量有問題的代碼可以加以改進，而架構方面的問題會導致更大的問題。我想我在一開始就應該更加關注應用程序的整體結構，而不是代碼的細節。

代碼質量很重要，但請注意，代碼質量并不是指我以前所認為的那些東西，比如 linting、格式化，等等。

5. 所有代碼都需要注釋

在加入第一家公司時，我需要處理大量別人留給我的代碼。我在干第一份工作時有做過一些類似的事情，但后來都沒有真正深入到已有的代碼庫，弄跟無頭蒼蠅一樣到處亂撞。我寧愿重寫所有代碼，也不想一點一點去理清楚老代碼是怎么寫的。

但即使是這樣又能怎樣？一個 Ruby 程序員寫出來的 AngularJS 代碼，或者一個自認為自己很厲害的初級程序員寫出來的代碼，別人照樣看不懂。

所以，我開始在所有可能的地方添加注釋，給所有函數加了注解。

我學會了所有與 Angular 相關的 JSDoc 語法。我的代碼行數因此增加了一倍，因為有太多的注釋。

我最終學到了什么

有時候注釋也會撒謊。有人把注釋當成了萬靈丹。“我們需要注釋！”不要因為寫注釋很難，就認為完全不值得這么去做，我只是認為要用正確的方式給需要注釋的地方加上注釋。錯誤的過度注釋只會給后面修復代碼 bug 的人添加更多的麻煩。

在適當的情況下用自動化代替注釋。自動化測試代碼通常不太會出現不同步的情況。我開始專注于編寫清晰的測試代碼，當其他人在閱讀我的代碼時就可以知道這些代碼是干什么用的。

6. 技術債務是不可容忍的

在很長一段時間里，我認為任何“混亂”的代碼都是技術債務。技術債務這個東西很有意思，如果你讓不同的人例舉技術債務的例子，他們會給出不同的答案。

因此，作為一個將“混亂”代碼視為技術債務的人，我會立即使用最嚴格的方式消除這類代碼！

我曾經花了一整個周末修復了 800 個 linting 錯誤（當然是在出現自動修復工具之前）。

可見我是一個多么神經質的人。

我最終學到了什么

不完美的代碼不一定就是技術債務。一些看起來不是那么好的代碼并不意味著它就是技術債務。技術債務會以某種形式阻礙項目的進展，或者讓你很難對項目做出變更。如果代碼有點美中不足，就放過它們吧，花太多時間清理它們可能不值得。

有點技術債務是正常的。有時候我們不得不走捷徑，因為時間緊迫。有一點技術債務是沒有問題的，只要記得回過頭來把這些債務還掉。如果你想讓你的項目零技術債務，那么你很可能把代碼本身凌駕在交付價值之上。我之前就是這樣的！

7.“高級開發者”就是指編程最厲害的人

因為從小就寫代碼，編程對我來說就像呼吸一樣。寫代碼就像在寫博客或者郵件，通常比別人更快給出解決方案。

在很長一段時間里，我一直在思考這個問題：這就是成為高級開發者要做的事情的嗎？

難道不是這樣嗎？因為頭銜是叫“高級開發者”，又不是叫“高級溝通者”或者“高級項目經理”，不是嗎？我不知道要成為高級開發者，除了編程還需要其他什么技能。

我最終學到了什么

高級工程師除了編程，還需要發展其他技能。與我已經掌握的技能相比，我還欠缺的技能簡直就是一個天文數字。從通信、依賴管理到共享上下文、項目管理、估算，以及與非開發人員合作。這些技能是不太好量化的，所以需要更多的試錯才能獲得。

不是每個人都能成為“高級開發者”。資歷是多年經驗積累的結果，但這也只是必要條件，而非充要條件。而且你的經驗還得是用得上的，你要把它們內化了，并可以用來解決問題。有時候，一些很重要的經驗需要一年甚至更長的時間才能顯化出來。

在某些領域，我們仍然很嫩。不管你的經驗多么豐富，總有很多東西是你不懂的。承認自己的“無知”是第一步，然后向更有經驗的人學習，爭取把中間的差距彌補起來。

原文鏈接：

https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的写了 10 年代码之后，我学到的 7 个绝对真理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。