進入 編程 開發 7 年，我學到了什麼？

前言：

相信每位開發者在本身開發的過程當中，都會反思一些問題，好比怎樣提升編程能力、如何保持心態不砍產品經理、996 以後怎樣恢復精力……

最近開發者 Tomasz Łakomy 將他 7 年的開發生涯中學習到的一些經驗分享了出來，這裏推薦給你，但願有所啓發。

Tomasz 講到了如下 6 個要點：

編程中最重要的語言

對於中國開發者來講，這個問題的答案多半是「英語」，然而 Tomasz 卻說：是英語，或者西班牙語、中文、波蘭語，或者其它任何你在工做中與他人交流所用的語言。

It's English.Or Spanish.Or Chinese.Or Polish.Or whatever you use to communicate with other people at work.

做者指出「與人交談比與機器交談更重要」。

編程是一項團隊運動，雖然存在極少數案例，我的能夠從零開發出很出色的產品，可是在絕大多數狀況下，編程工做須要一個團隊。

溝通技巧能夠決定項目的成敗，甚至 NASA 也由於這個問題而困擾。項目想要得到成功，總體的專業技能比純技術技能更爲重要，

舉個例子，若是你聘用了世界上最好的五位數據庫專家，可是他們之間拒絕交流，沒有協同工做，那最後交付給你的多是 MySQL、Aurora 與 MongoDB 的五個不一樣實例，那又有什麼意義？

深刻了解你正在開發什麼？爲何開發它？

大多數人在有目標感時會更開心，這也適用於工做。做爲軟件開發人員，你的目標不是用 JavaScript 實現 JIRA，或者用 C# 重寫 Trello，你的目標應該是解決代碼問題。

若是你對正在開發或者維護的系統有深刻的瞭解，那麼就能夠在純技術以外作出決策。這個功能是必要的嗎？它解決了什麼問題？咱們能以其它方式解決這個問題嗎？這個問題的優先級這麼高合理嗎？

這種思路有時被稱爲「業務上下文」，但若是你想作好本身的工做，你不只應該瞭解這些上下文，還要可以塑造和影響它。這不是說你必須在組織中擁有某個高級職位才能這麼去作，你至少要先去了解這些內容。

代碼審查

不要背地裏審查別人的代碼，而且公開指出其中的問題，你在初級開發者的代碼 PR 下以很差聽的言論挑出了一些問題，這樣並不能證實你有多厲害，相反，這只是說明你不是一個友善的人。

可是若是真的發現別人實現的功能徹底無效，那麼怎麼辦呢？合適的作法是私下去聯繫代碼的編寫者，與他們交流，找出他們爲何會以這樣的方式實現該功能。

大多數人都不會想着說要寫出很差的代碼，若是他們的代碼你以爲不行，那多是他們在處理一些你沒注意到的限制問題；或者他們確實編程能力還不夠強，那這個時候就是你展示實力，幫助他們解決問題的時候了。

有些事情會出錯，作好準備

「任何可能出錯的事最終都會出錯」，墨菲定律很可怕，你要始終假設在設計系統時可能會出現問題。

若是你正在構建登陸表單，須要假設用戶會將整本書複製並粘貼到密碼字段中；若是你正在寫一個 WYSIWYG（所見即所得）窗口，要假設有人會試圖破壞它，而且他們極可能會成功；若是你有一個數據庫，假設它會在某個時候出現故障；若是你尚未測試從 backup 中恢復數據庫，那麼這就不是一個 backup；若是你正在觀衆面前進行現場演示，須要確保 demo 在線上或者離線等狀況下都能正常展現。

不要懼怕說「我不知道」

剛開始當程序員的時候，可能你會懼怕別人發現你不懂某一個問題，因此別人問你而你真的不懂的時候，你不會直接回答說你不知道，而且會給出一些不能肯定的答案，可是自己沒有底氣，因此會懼怕別人知道真相後以爲你是個騙子。

可是做爲開發者幾年以後，你可能會以爲若是一個東西你還不知道，那可能它是可有可無的，或者這是你須要如今去學習的另外一項新技術。

終身學習不是軟件開發的流行語，它是現實。

保持這樣的心態，這個時候，當別人問了一個你不懂的問題時，你就能夠大膽地說：我不知道，我尚未試過，我先看看，而後回覆你。

分享學習成果

當你從「我不知道」的狀態中學習到某項新技術的時候，這時候能夠去與他人分享你的學習成果。好比寫本身的博客、錄製視頻教程、在公司的分享活動中演講，或者只是簡單地把知識點告訴另外一我的。

二次教學是考驗你是否真正理解你所學的東西的極其有效的手段，並且通常來講，即便是最資深的專家也能夠從初學者那裏學習到新東西，這樣對於你和其餘人來講是共贏。

做爲開發者，你工做了幾年？在工做過程當中學習到了什麼呢？

做爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要這是一個個人iOS交流羣：638302184，無論你是小白仍是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 你們一塊兒交流學習成長！