初入軟件「江湖」的萌新需要了解的五個經驗教訓
大概四年前我獲得了計算機科學學位并開啟了軟件工程師的職業生涯。我將在這篇文章中分享一些我這一路過來學習到的經驗教訓。先歸納一下：
- 不要假設
- 非技術問題才是最困難的
- 先思考，再寫代碼
- 你要創造的東西比用于創造它的工具更重要
- 每個角色都同等重要
不要假設
在我開始***份工作后，我的***個項目是一項長期運行的項目中一個短期任務。這個項目已經經歷過很多開發周期和很多開發者。它有很大很復雜的代碼庫，而且整合了很多外部服務。
我的***個任務是修復一些會間歇性故障的單元測試。要測試的代碼相對老舊，是一位資深開發者曾經編寫的。因為從 UI 看其功能效果良好，并且 QA 也徹底地測試過它，所以我就假設問題*肯定*和測試本身有關。
我花了近三天時間想要修復本來沒有問題的測試方法。當我向我的團隊領導解釋修復工作耗費如此長時間的原因時，他教給了我重要的***課。他告訴我說：不要只是因為別人的代碼看起來像是正確的就假設它確實正確。
這可能是我學到的最重要的教訓，而且這一教訓可應用于很多場景，而不僅是代碼相關領域。舉些例子：
不要只是因為你叫過某人去做某些事就假設他確實會做。永遠記得要達成明確的一致。你讓某人去檢查某些東西但還未得到答復?那就去跟進一下。如果某些事情是重要的，那就值得保持跟進。
不要假設別人理解你告訴他們的內容，即使他們說自己確實理解。這個教訓是我的職業生涯進入到幫助指導更多初級開發者時所學到的。我發現我會快速說完指令，然后第二天跟進時卻發現相關的開發者沒什么進展，即使當時他們說過已經***地理解了需求。相反，你應該讓那個人復述一遍討論過的內容，這樣你才能確保他們確實理解了。這個經驗不僅適用于指導開發者，也可用于向 BA/QA 解釋等等。
不要假設對方是錯的。我發現開發者在自己的代碼無效時往往傾向于責備他人。你對你寫的代碼有保護欲，甚至會達到說服自己相信不可能出錯的程度。如果 QA 告訴你他們遇到了一個問題，他們有理由這么做。消除他們的疑慮不會給你太多損失，而且比起被拒絕，他們也會更加感激。
非技術問題才是最困難的
在大學里時，所有的問題都是技術方面的，要解決的問題不過就是想辦法讓代碼有效工作。但是進入職業生涯后，我發現情況很少再會是這樣了。
對于一個跨多個時區工作的大型團隊而言，確保溝通至關重要。要確保流程有效，要有清楚的文檔記錄。要確定提供幫助或指導新團隊成員的方法。為開發過程引入新東西時，要確保平滑過渡。當數據數字著眼于推動當前的議程時，要說服項目管理注重長期的代碼健康。
這只是你在參與項目時會遇到的一部分事情。在我看來，比起追蹤困擾你的空指針，這些問題可要難多了。
先思考，再寫代碼
你發現了一個可以改進的流程。你立馬決定將其自動化。你投入了所有的空閑時間開發能完全改變你的團隊的工作方式的東西。
聽起來很熟悉，對吧?包括我在內，開發者都熱愛自動化解決方案。
我的經驗教訓是什么?不要直接寫代碼。停下來想想問題，而不是解決方案。和更廣泛的人交談一下，而不只是開發者。首先搞清楚這究竟是一個技術問題還是一個流程問題。然后再尋找解決方案。
當然，使用 Docker 和已寫好的***腳本構建一些復雜的解決方案確實很炫酷，而且你可能也能學到很多，但為非技術問題提出技術解決方案可能無助于團隊的長期工作。這可能掩蓋更大的問題。
你要創造的東西比用于創造它的工具更重要
我剛畢業時非常熱愛寫代碼、學習新語言和框架以及任何涉及到技術元素的東西。
不要誤會，我現在依然熱愛。但是，我后來意識到，只要我們開發者使用的工具能讓我們完成工作，那么工具究竟是什么其實不重要。在前端開發中，每隔幾天就會有一種新框架。盡管開發者跟進這些進展很重要，但最終用戶(重要的人)并不在乎工作原理，只要有效就行。
每個角色都同等重要
我已經提到了不要自動假設非開發者是錯誤的的重要性。除那之外，我也學習到構成你團隊的每個成員(BA、QA、項目經理、其他利益相關者等等)都和所有開發者一樣重要。
如果沒有每個角色的努力，項目是不會有成果的;類似地，如果不在各種資源類型之間平等地共享資源，項目也不會有成效。
我還學習到，即使確實是開發者寫出了實際的代碼，但如果沒有利益相關者，代碼就沒有價值;而如果不能在質量上保證這些代碼能完成工作，也不會有利益相關者。
總結
希望你能從這些經驗教訓中學到些東西。你在職業生涯中收獲了哪些有用的經驗，不妨也與我們分享!
原文鏈接：
https://medium.freecodecamp.org/five-important-lessons-from-four-years-as-a-software-developer-9b367f256226
【本文是51CTO專欄機構“機器之心”的原創譯文，微信公眾號“機器之心( id: almosthuman2014)”】
