「傻瓜」才能寫出好程式碼！
作者 | Esteban Gabriel
譯者 | 彎月
責編 | 仲培藝
出品 | CSDN（ID：CSDNnews）
我覺得自己沒有想象中那麼聰明，而且還是一個健忘的人。正因如此，我寫的程式碼才能一天比一天好，想知道為什麼嗎？
在過去的九個月裡，我暗暗下定決心要成為一個“更加優秀”的程式設計師，而且還要直面困難，迎難而上。
大約在一年半前，我開始自我改造，而上述種種只是計劃中的一部分，但本文我想重點聊聊程式設計。
讓我們來看看經過九個月的努力，我都學會了什麼——
自我剖析
首先，我決定直面一個於我而言最大的挑戰：我是個沒有條理的人，行動前缺乏深思熟慮，而且過於自信。這些缺點加在一起簡直慘不忍睹，但是一直以來我的行事風格一貫如此，而且大多數情況下日子過得還算馬馬虎虎，但是在我深知自己還可以做得更好。所以我決定逐個克服這些缺點。
行動前深思熟慮
以前我的表現就像一隻小狗，看到主人扔出小棍子，就奮不顧身地撲上去撿。每次拿到新的需求，我會不經大腦思考就一頭扎進鍵盤裡，將我認定的解決方法寫成程式碼。
現在，每當遇到新的需求時，我就會想起鋼琴老師在課堂上對我講過的一句話：
首先，把你的手從鋼琴上拿下來，深呼吸，做好準備，然後再開始表演。
想到這句話，於是我開始在紙上或用 draw.io（有時候我用這個工具記筆記）寫出解決方案的虛擬碼。這個過程可以讓我看到各個元件之間的互動、它們的職責劃分（SOLID 原則），乃至設計模式。
如果開發過程發生了變化，那麼我也會相應地更新我的筆記，以符合真實的解決方案。
沒有條理
我強迫自己一步一步寫下為了完成任務需要做的事情。在 Jira/Trello 中建立子任務列表，在顯示器上貼便利貼，或在 IDE 的文字編輯器中寫詳細註釋。這些主要是為了檢查我在解決任務時所做的每一步。
這樣做的第一個好處是可以減少工作中的健忘。一般來說，開發人員都面臨著很多需要完成的任何，還需要考慮很多極端例子，所以我們很容易忘記一些關鍵點。
如果可以向別的同事展示你為解決方案建模的方法就更好了，也許他們之中有人可以看出一些可能存在的邏輯錯誤或你未發現的邏輯。
一般來說，我在做完整體的構思後會立即做這一步，因為這些步驟對應著上一步中構思的元件以及各個元件的職責。
做完這些，我就有了整體的構思以及詳細的工作步驟。但這並不意味著情況不會發生變化，因為系統開發中的每個過程都是迭代的，並且需要及時調整實際的實現。
健忘
對付健忘的好方法就是記下來。但你不必非要畫出標準的 UML 圖表，一般的 IDE 都可以在多個檔案和方法之間來回切換，這樣就可以輕鬆地遵循解決方案的流程了。但是，每個開發人員都會面臨這種情況：
開發→重構→完成→過段時間/開始新功能→上次開發中的 bug→修復 bug→過段時間/繼續做沒做完的功能......依此類推。
支援舊功能會導致舊程式碼、新程式碼、修復 bug 的程式碼以及所有可能的程式碼之間盤根錯節：你需要記住整個功能的工作原理。出於這個原因，我使用 Javadoc 或 JSDoc 在方法開頭做詳細註釋，或者用一個簡單的註釋來描述這個方法的目的是什麼。
如果你是為了應用程式的將來更新程式碼，那麼也請你為了你和你的夥伴們的未來更新註釋。
冒傻氣
正如本文的標題所示，我的為人很有幾分傻氣。
我需要知道正在開發的功能的每個互動案例，這樣才有了參照，我才能知道我所做的東西是對還是錯。有一段時間我做了一些傻事，在遊戲玩家術語中被稱為“臉探草叢”，意思是說拿身體探，而不是用技能，一般來說這都是測試人員的工作。如果他們在測試環境中發現每個部署中都存在大量 bug，則意味著這些程式碼未經過我的測試。
有一種很讓人頭疼的現象是：程式碼中的 bug 比我需要修復的還要多。在大多數情況下，每次發現 bug 回過頭去改舊功能就意味著我需要中斷手頭正在開發的新功能。這種上下文的切換（舊功能/新 bug 與正在開發的新功能之間的切換）真的很煩人。
所以在決定的時候，我認為最好的選擇是：測試我的程式碼。我指的不是功能測試，功能測試肯定是要做的，我指的是技術方面的測試——單元測試和整合測試。這聽起來很像廢話，很多人都會回一句“那還用說嘛，這是你必須做的，這是基本規則。”但事實上，並非所有開發人員都能做到這一點。我發現測試不僅可以減少由於 bug 造成的開發中斷，而且還可以驗證我正在開發的解決方案的應用場景，對我來說是雙贏的。
我無意宣揚程式碼測試的神奇，事實上測試擁有完整的體系，而且已經很多年了。我只是想告訴你，我發現測試可以提高我的程式設計技巧和程式碼質量，而且希望你也開始這麼做。
首先，測試花費的時間很多，但是測試你的程式碼應該成為一種習慣。一旦測試成為程式設計工作的一部分，那麼你會自動編寫單元測試和整合測試。這不是魔法，只是工作，但是我可以保證你將獲得豐厚的回報——bug 更少，解決方案更清晰，同時還能很好地理解你的解決方案及其在不同場景下的工作方式。
你已經掌握了一切嗎？
距離心目中那個理想的自己，我還未及一半。但是每天我都會關注可以提升自我的方法。與你做分享也許對我有所幫助，我說的這些可能你心知肚明，但由於種種原因你並沒有付諸行動。我也想告訴那些跟我一樣在程式設計工作上“做傻事”的人，你並不孤單。
我將繼續努力總結出更加具體的方法，因為我從中獲益匪淺。我並不會在每個問題上都採用這些步驟，除了測試，因為測試是必不可少的，但是在對我、我的夥伴們以及程式有幫助的時候，我也會擬定一定的順序，並理清需求。
最後，我想說：我們還有很多工作需要做，有很多東西需要學，還有很多挑戰需要實現。
原文：https://medium.com/@garciawarneckee/because-im-dumb-i-write-better-code-f7e355722131
本文為 CSDN 翻譯，如需轉載，請註明來源出處。
【完】
熱 文 推 薦
☞ 官宣：Linux 核心主要貢獻者 Linaro「喜提」新任 CEO！
☞ 年後跳槽 BAT 必看，10 種乾貨幫你 Offer 拿到手軟！
print_r('點個好看吧！');
var_dump('點個好看吧！');
NSLog(@"點個好看吧！");
System.out.println("點個好看吧！");
console.log("點個好看吧！");
print("點個好看吧！");
printf("點個好看吧！\n");
cout << "點個好看吧！" << endl;
Console.WriteLine("點個好看吧！");
fmt.Println("點個好看吧！");
Response.Write("點個好看吧！");
alert("點個好看吧！")
echo "點個好看吧！"
點選“閱讀原文”，開啟 CSDN App 閱讀更貼心！