|
時間如梭，不是嗎？ 我的編程之旅始于 2012 年，當時我還只是個 C++ 編程實習生。說實話，我根本不知道自己在做什么。即使是到了現(xiàn)在，這種狀況依然沒有改變。不過，在這個過程中，我確實學到了很多東西。 問題來了：在編程過程中，什么語言才是最重要的？ 是英語？西班牙語？中文？波蘭語？還是其他在工作中用來與其他人進行溝通的語言？ 編程是一項團隊活動。很少有出色的軟件產(chǎn)品是完全由一個人從頭到尾做出來的（CodeSandbox 算是一個，但后來 Ives 還是請了一些人），大多數(shù)產(chǎn)品需要一個團隊來打造。 溝通技巧可以成就一個項目，也可能會毀了它。相比存粹的技術(shù)，軟技能對一個項目的成功起到更重要的作用。試想一下，你把世界上最好的 5 個數(shù)據(jù)庫專家都請來了，但如果他們各自為政，互不溝通，最后他們會給你搞出 5 個不同的 MySQL、Aurora 或 MongoDB 實例。 人一旦有了目標感，就會感覺好一些，這在工作中也是一樣的。 作為軟件開發(fā)人員，你的目標不應(yīng)該只是把 JIRA 中的問題變成 JavaScript，或者把 Trello 中的項目變成 C#。 你的目標應(yīng)該是用代碼來解決問題。 如果你對正在構(gòu)建或維護的系統(tǒng)很了解，就可以拋開技術(shù)做決策。這個功能是必需的嗎？它解決了什么問題？可以用其他方式來解決這個問題嗎？真的有必要解決這個問題嗎？ 這些都是業(yè)務(wù)問題，如果你想把工作做好，不僅要理解這些業(yè)務(wù)，還要主動參與其中。即使你在公司里不是 C 級別的人，也不影響你這么做，至少，你要明白自己在做什么。 雖然我們沒有必要那么想，但把自己寫的代碼放出來讓其他人“圍觀評論”，這種體驗跟寫代碼還真是有點不一樣，也難怪人們會感到焦慮。 有人因為不坎忍受某些人的吹毛求疵，選擇在這個人不在公司的時候提交代碼評審。試想，如果你在一個新手的 PR 底下轟炸式地給出 50 個不那么友好的評論，你其實不只是在證明自己作為一名高級程序員的優(yōu)越感，也是在證明你不是一個“好人”。 那么，正確的打開方式應(yīng)該是怎樣的？ 你可以私底下找那個人，跟他好好聊聊，問他為什么把代碼寫成那樣。 其實大多數(shù)人也不想把代碼寫臭，如果你看到臭代碼，可能其中會有一些不為人知的原因。當然，也有可能是因為他們的編程技能還不夠好，這個時候你要承擔起“導師”的角色，給他們提供一些指導。
這就像是一個真理，在設(shè)計系統(tǒng)時總會有一些東西會出錯。 在開發(fā)一個登陸表單時，你要假設(shè)會有一些居心叵測的人把整本書的內(nèi)容拷貝到密碼輸入框里。 在開發(fā)一個可見即所得的窗口時，你要假設(shè)會有人試圖搞破壞，而且他們通常都能如愿以償。 如果系統(tǒng)中使用了數(shù)據(jù)庫，它一定會在某個時刻掛掉。如果你沒有嘗試使用備份來恢復數(shù)據(jù)庫，那它們就算不上是備份。 如果你在給別人做演示，請確保這個演示在任何情況下都能正常進行，哪怕把它翻個底朝天，甚至是把它丟到水底下。 作為高級程序員的一個好處是，當別人問一些我不懂的問題時，我可以很淡然地告訴他們： 這個東西我也不懂，因為以前沒有遇到過，不過我可以看一下，然后再告訴你。 當我還是一個初級程序員的時候，我總是很害怕別人會看到我的無知。經(jīng)過幾年的磨練，我才明白，如果碰到了自己不懂的東西，說明學習的機會來了。終身學習絕對不只是一個“口頭禪”，它應(yīng)該被付諸實踐。 等你把不懂的東西搞懂了，就要把它們分享出來。寫一篇博客，錄個教學視頻，或者在公司里搞個分享演講……你不要認為你剛學會的東西別人也都懂，即使是一個非常資深的人，他們也能從初級人員身上學到東西，反過來也是。 分享的過程其實是一個檢驗?zāi)闶欠裾嬲斫馑鶎W的東西的過程。有句話說得好：
|
|
|
