像寫散文一樣寫代碼

Python部落(python.freelycode.com)組織翻譯，禁止轉載，歡迎轉發。

引言

我喜歡寫散文，當然也喜歡寫代碼。

不同的人有不同的編寫代碼方法。我有一個同事，他編寫好的軟體的標準是確保不用滾動就能讀取一個代碼塊。下面是我關於好代碼的評判標準：

「任何人都能寫出計算機理解的代碼，好的程序員應該寫出人類理解的代碼」

換言之，正如Nicholas Zakas在維護JavaScrit中所說，打開一個空白編輯器寫新代碼，如果已經存在的話就是維護代碼。一般來說，我們花費很少的時間寫新代碼，大多數時間都是在維護已有的代碼。對我來說，好的代碼就是不用調試就能夠理解的。

一直以來我都相信寫代碼和寫作文之間有很多相似的地方，比如，在代碼頂部加個注釋就像在帖子開頭加個引言一樣。

提綱

寫作文之前我喜歡列個提綱，它不一定是完美的，也不一定是最終的形式，但是它非常有利於組織思路。一旦列完提綱，剩下的寫作就相當容易。

由此，提綱對於寫軟體也是一個不錯的工具，就像測試驅動開發(TDD)一樣，不需要大的前期投資。通常，我喜歡花一點時間來調查我添加的功能，它可能有什麼樣的界面，以及一些最可能的用例。有時我可以用實際的大綱來做，有時候我創建一個流程圖，有時候我只是用手畫一些東西。關鍵是在著手構建之前知道自己要做些什麼。

草稿

列完提綱之後就可以嘗試寫出要點了，此時不必在意質量，因為之後還要進行校對工作。

和寫代碼一樣，一旦我有一個大概的想法要實施，我將會建立一個新分支來進行。驅動測試最大的問題就是限制太多，坐下來寫代碼的一半時間都不知道如何結束。建立不同的分支可以讓我隨時測試不同的功能。

校對

寫完草稿，我喜歡回頭大聲朗讀我的作文，就像進行一場對話一樣。結果是重寫一些句子與段落，有時候會刪除大段的文字濾去那些沒用的詞句。對於代碼我喜歡進行同樣的操作，此時，我已經知道要建立什麼，仍然可以自由的重構代碼，讓它們更容易測試。

重命名變數和函數也是一個不錯的檢查機會，在此期間，我喜歡想像自己第一次閱讀我的代碼並告訴我的代碼實現怎樣的功能。如果我認為它會使我的代碼更易讀，我不怕添加額外的變數，同時也不怕刪除額外的變數。

我的一般經驗是，一個好的名字比一個好的注釋更好，當然最好什麼都沒有就能讓人看明白：名字>注釋>Nothng。

二次校對

即使過一段時間進行最後的校對，自己也總會漏掉一些東西，通常一個人對自己的作文都認為是不錯的，沒有什麼問題。這時，我會讓我的妻子幫我進行檢查。

對於代碼也是如此，這就是為什麼我這麼看重請求與評論的原因，它們通常會給我一個全新的視角。

修正錯誤

寫作從來都不是完美的，我總是歡迎反饋，無論是積極的還是消極的，因為它給了我一個更好的修正機會。與軟體一樣，我努力不破壞最初的工作，但是我接受發生的錯誤。在寫作時，我會注意人們對我的工作看法。在寫代碼時，我會注意用戶對我的軟體和審核日誌的評論。這樣我能及時排除意外的錯誤。

總結

在總結寫作與寫代碼的過程中我不能找到一個合適的平衡點，或許有人能夠在評論中幫助我。正如我所說的那樣，對於計算機我們只用0和1來寫代碼，但是我們要為人們寫出高水平的可維護的代碼。

英文原文：https://www.alexkras.com/writing-code-is-a-lot-like-writing-prose/
譯者：Mr Chen

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！