5年程式設計師生涯，我學到最重要的6個教訓

時間如梭，不是嗎？

我的程式設計之旅始於 2014 年，當時我還只是個網頁製作的 實習生。說實話，我根本不知道自己在做什麼。即使是到了現在，這種狀況依然沒有改變。不過，在這個過程中，我確實學到了很多東西。

問題來了：在程式設計過程中，什麼語言才是最重要的？

是英語？西班牙語？中文？波蘭語？還是其他在工作中用來與其他人進行溝通的語言？

瞭解你在做什麼以及為什麼

人一旦有了目標感，就會感覺好一些，這在工作中也是一樣的。

作為軟體開發人員，你的目標不應該只是把 JIRA 中的問題變成 JavaScript，或者把 Trello 中的專案變成 C#。

你的目標應該是用程式碼來解決問題。

如果你對正在構建或維護的系統很瞭解，就可以拋開技術做決策。這個功能是必需的嗎？它解決了什麼問題？可以用其他方式來解決這個問題嗎？真的有必要解決這個問題嗎？

這些都是業務問題，如果你想把工作做好，不僅要理解這些業務，還要主動參與其中。即使你在公司裡不是 C 級別的人，也不影響你這麼做，至少，你要明白自己在做什麼。

如果程式碼評審讓你感到有壓力，那肯定是開啟方式出錯了
雖然我們沒有必要那麼想，但把自己寫的程式碼放出來讓其他人“圍觀評論”，這種體驗跟寫程式碼還真是有點不一樣，也難怪人們會感到焦慮。

有人因為不坎忍受某些人的吹毛求疵，選擇在這個人不在公司的時候提交程式碼評審。試想，如果你在一個新手的 PR 底下轟炸式地給出 50 個不那麼友好的評論，你其實不只是在證明自己作為一名高階程式設計師的優越感，也是在證明你不是一個“好人”。

那麼，正確的開啟方式應該是怎樣的？

你可以私底下找那個人，跟他好好聊聊，問他為什麼把程式碼寫成那樣。

其實大多數人也不想把程式碼寫臭，如果你看到臭程式碼，可能其中會有一些不為人知的原因。當然，也有可能是因為他們的程式設計技能還不夠好，這個時候你要承擔起“導師”的角色，給他們提供一些指導。

未雨綢繆

墨菲定律：會出錯的事情就一定會出錯。

這就像是一個真理，在設計系統時總會有一些東西會出錯。

在開發一個登陸表單時，你要假設會有一些居心叵測的人把整本書的內容複製到密碼輸入框裡。

在開發一個可見即所得的視窗時，你要假設會有人試圖搞破壞，而且他們通常都能如願以償。

如果系統中使用了資料庫，它一定會在某個時刻掛掉。如果你沒有嘗試使用備份來恢復資料庫，那它們就算不上是備份。

如果你在給別人做演示，請確保這個演示在任何情況下都能正常進行，哪怕把它翻個底朝天，甚至是把它丟到水底下。

不要害怕讓別人看到自己的無知

作為高階程式設計師的一個好處是，當別人問一些我不懂的問題時，我可以很淡然地告訴他們：

這個東西我也不懂，因為以前沒有遇到過，不過我可以看一下，然後再告訴你。

當我還是一個初級程式設計師的時候，我總是很害怕別人會看到我的無知。經過幾年的磨練，我才明白，如果碰到了自己不懂的東西，說明學習的機會來了。終身學習絕對不只是一個“口頭禪”，它應該被付諸實踐。

分享

等你把不懂的東西搞懂了，就要把它們分享出來。寫一篇部落格，錄個教學影片，或者在公司裡搞個分享演講……你不要認為你剛學會的東西別人也都懂，即使是一個非常資深的人，他們也能從初級人員身上學到東西，反過來也是。

分享的過程其實是一個檢驗你是否真正理解所學的東西的過程。有句話說得好：

當你在教一個人的時候，其實有兩個人在學。

為了幫助大家讓學習變得輕鬆、高效，給大家免費分享一大批資料，幫助大家在成為前端工程師，乃至全棧工程師的路上披荊斬棘。在這裡給大家推薦一個前端全棧學習扣qun：784783012 無償分享一些資深前端開發工程師錄製的影片錄影（從零基礎到專案實戰案例），前端工程師必備的知識體系。還能領取免費的學習資源
當真正開始學習的時候難免不知道從哪入手，導致效率低下影響繼續學習的信心。
但最重要的是不知道哪些技術需要重點掌握，學習時頻繁踩坑，最終浪費大量時間，所以有效資源還是很有必要的。