七年程序員生涯，我學到的重要六課

時間如梭，不是嗎？

個人編程之旅始於 2012 年，當時我還只是個 C++ 編程實習生。說實話，我根本不知道本身在作什麼。即便是到了如今，這種情況依然沒有改變。不過，在這個過程當中，我確實學到了不少東西。

問題來了：在編程過程當中，什麼語言纔是最重要的？

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

 與人溝通比與機器溝更重要

編程是一項團隊活動。不多有出色的軟件產品是徹底由一我的從頭至尾作出來的（CodeSandbox 算是一個，但後來 Ives 仍是請了一些人），大多數產品須要一個團隊來打造。

溝通技巧能夠成就一個項目，也可能會毀了它。相比存粹的技術，軟技能對一個項目的成功起到更重要的做用。試想一下，你把世界上最好的 5 個數據庫專家都請來了，但若是他們各自爲政，互不溝通，最後他們會給你搞出 5 個不一樣的 MySQL、Aurora 或 MongoDB 實例。

 瞭解你在作什麼以及爲何

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

做爲軟件開發人員，你的目標不該該只是把 JIRA 中的問題變成 JavaScript，或者把 Trello 中的項目變成 C#。

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

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

這些都是業務問題，若是你想把工做作好，不只要理解這些業務，還要主動參與其中。即便你在公司裏不是 C 級別的人，也不影響你這麼作，至少，你要明白本身在作什麼。

 若是代碼評審讓你感到有壓力，那確定是打開方式出錯了

雖然咱們沒有必要那麼想，但把本身寫的代碼放出來讓其餘人「圍觀評論」，這種體驗跟寫代碼還真是有點不同，也難怪人們會感到焦慮。

有人由於不堪忍受某些人的吹毛求疵，選擇在這我的不在公司的時候提交代碼評審。試想，若是你在一個新手的 PR 底下轟炸式地給出 50 個不那麼友好的評論，你其實不僅是在證實本身做爲一名高級程序員的優越感，也是在證實你不是一個「好人」。

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

你能夠私底下找那我的，跟他好好聊聊，問他爲何把代碼寫成那樣。

其實大多數人也不想把代碼寫臭，若是你看到臭代碼，可能其中會有一些鮮爲人知的緣由。固然，也有多是由於他們的編程技能還不夠好，這個時候你要承擔起「導師」的角色，給他們提供一些指導。

 未雨綢繆

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

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

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

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

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

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

 不要懼怕讓別人看到本身的無知

做爲高級程序員的一個好處是，當別人問一些我不懂的問題時，我能夠很淡然地告訴他們：

這個東西我也不懂，由於之前沒有遇到過，不過我能夠看一下，而後再告訴你。

當我仍是一個初級程序員的時候，我老是很懼怕別人會看到個人無知。通過幾年的磨練，我才明白，若是碰到了本身不懂的東西，說明學習的機會來了。終身學習絕對不僅是一個「口頭禪」，它應該被付諸實踐。