戰五渣程式設計師的五項必備技能
- 2019 年 11 月 25 日
- 筆記
作者 | Ravi Shankar Rajan 翻譯 | 漫慢忙
本文翻譯自 Ravi Shankar Rajan 的 5 Toxic Habits That Will Make You a Bad Developer.，請對照原文閱讀。
你無法改變自己的未來，但你可以改變自己的習慣，而你的習慣肯定也會改變你的未來。
「習慣的束縛太輕了，以至於它們變得沉重而無法被打破。」 --- 沃倫·巴菲特
當我們因為自己的不良習慣感到不適時，就會四處尋找解決方案。我們會去翻書或求助於他人，期望能知道如何去擺脫它。然而實際情況是，打破任何不良習慣僅取決於「鏡子里的人(the man in the mirror)」。你期望變得更好，做一些不同的事情。一旦你掌握了改變的範式，擺脫不良習慣就變得很容易。
如同生活一樣，編程也有好習慣和壞習慣。能否成為一個優秀的程式設計師，取決於你能否有效地控制編碼中的不良習慣。你反覆做的事情會影響你的行為，你所相信的事物以及對整個世界的看法。簡而言之，養成好習慣還是壞習慣，都取決于思維。
如果你意識不到自己的所做所為正在破壞你的工作，那麼壞習慣就很難消除。你仍然自我感覺良好，並且會繼續陷入效率低下和程式碼品質差的泥潭。
作為一個自學成才的開發人員，我對於不良習慣帶來的後果可謂經驗豐富。但是現在我知道自己犯了什麼樣的錯誤，並學會了避免將來犯下同樣的錯誤。我仍在學習，並且日新月異。
這裡有一些有害的習慣，這些習慣會使你成為一個糟糕的開發人員。
沒有計劃的編碼
「我總是發現計劃是無用的，但是計劃卻又是必不可少的。」 --- 艾森豪威爾將軍
不幸的是，許多開發人員（包括我自己）都常常會想：「我可以輕而易舉地做到這一點」，而最終結果卻很差。我們沒有認真思考就開始工作，最後到項目截止時間時，還有一堆的需求沒完成，而程式碼也是亂七八糟的。
而如果在編碼之前能花些時間來分析需求，將需求分解為可管理的模組，並與同事和業務分析師進行一些頭腦風暴，然後依此提出一個漸進式計劃，則可以幫助我們創建高品質的程式碼。利用紙筆，或白板，甚至是和小黃鴨交談，然後提出一個可跟蹤的有序的計劃。
請記住，你無法計劃所有事情。解決問題的第一個計劃可能是完全錯誤的，不過沒關係。重要的是，當你完成初稿時，你能清楚地知道差距在哪裡，以及需要在怎樣來填補這些差距。計劃很重要，但計劃也會不經意間發生變化。
對程式碼審查心懷戒備
「我們大多數人的問題在於，我們寧願被讚美毀滅，也不願受到批評的拯救。」 --- 諾曼·皮爾（Norman Peale）
批評可能令人無法接受，但卻是必要的。它與肉體上的疼痛一樣，能讓人們關注到自身的不健康狀態。你可能自認為是世界上最好的開發人員，但你的程式碼的表現卻不盡然。你越早意識到這個事實，就能越快成為一個優秀的程式設計師。
你需要謙虛地對待在程式碼審查過程中檢測到的錯誤或缺陷，並確保後續不會再犯同類的錯誤。糟糕的開發人員對此卻無動於衷，最終只會害人害已。
優秀的開發人員願意將自己的程式碼拿出來公開討論，並不斷改進。他們不會被自己的牛逼的解決方案蒙蔽，願意接受自己的無知，並且不斷地學習新事物。
表現得無所不知
不了解所有事情，有時候是件好事 --- 尼爾·蓋曼（Neil Gaiman）
糟糕的開發人員不承認自己無知的原因有很多。害怕被嘲笑，自我膨脹，害怕受到譴責等。但不管是什麼原因，最終他們在知識獲取和聲譽上都會是失敗者。行為經濟學暢銷書《狂熱經濟學》的作者斯蒂芬·J·杜布納和史蒂文·D·萊維特提出這樣的觀點：最難說有三個字不是 "I love you"，而是 "I don』t know"。
需要記住，說 "I don』t know" 是完全可以的。這比掩蓋你缺乏某些知識/技能要好得多。這裡的關鍵是要知道如何解決問題 -- 可以通過詢問他人或進一步調查研究。
與其執著於應該無所不知的烏托邦式夢想，不如將世界視為學習的基礎。你應該隨時隨地接受新的，不同的或變化的觀點，並根據變化的情況調整解決問題的能力。
以程式碼行數來衡量進度
「通過程式碼行數來衡量編程進度就像通過重量來衡量飛機製造進度。」 --- 比爾·蓋茨
「我可以在一個通宵工作中編寫10,000行程式碼」。
「你看到那個項目了嗎？那都是我的。我為此寫了30,000行程式碼」
「我有自己的編碼風格。無論別人做什麼，我都會按照自己的方式進行編碼」
聽起來很熟悉吧？這就是所謂的程式設計師自我。用自己的方式做事並重寫現有程式碼可能會滿足你的自我，但肯定不能滿足項目的需求。
作為開發人員，你的工作應該是編寫儘可能少的程式碼來滿足需求。當得到一個新的功能需求時，應該首先問自己：「有人做過嗎？我可以重複使用它嗎？」借用現成的解決方案沒有什麼可恥的，因為任何軟體的創建通常都是團隊合作的結果。應該始終希望整個團隊堅如磬石，而不只是個體的拼湊。
為自己省去一些麻煩。不要重複自己。不要在程式中重複相同或幾乎相同的程式碼。而是將程式碼放入一個可以處理多種情況的類或函數中。如果有人已經為你做到了，那就無恥地去使用它。
推卸責任
優秀的人善於自省，自卑的人責備他人 --- 唐·舒拉（Don Shula）
軟體開發是一項團隊運動。Agreed
軟體開發是集體協作。Agreed
因此，我不對我的程式碼負責。Not OK
在開發人員中有些自大和傲慢的態度也不是什麼秘密。因此，承認犯了錯誤並確認生產問題是由你編寫的程式碼引起的，這需要非常謙虛和無私的態度。將問題歸咎於他人很容易。但查找過去的程式碼並找出導致錯誤的原因對解決問題會更有效率。
大家都會重視那些對自己的程式碼負責並確保以後不會犯同樣錯誤的開發人員。軟體不可能永遠是完美的。瑕疵將永遠存在。關鍵是要控制缺陷，並追求卓越。
從現在開始，你應該努力使自己和他人的程式碼儘可能地可讀。記住，如果你不敞開心扉來承認自己的錯誤，那實際上也得不到成長。
正如沃爾特·惠特曼所說的一樣：
Be curious, not judgmental.
