[[374545]]

編程很像寫作 —— 你應該從一個能用的“不完美的初稿”開始，再通過兩三次修改，逐個解決初稿中存在的問題。

工程師們肯定會嘲笑自己居然被輕率地比作了”作家“—— 但是今天早上的文檔又是誰寫的呢?你不是在“寫代碼”嗎?

軟件開發人員從事著最具創意的工程類型的工作。畢竟，與構建橋梁的土木工程師相比，軟件工程師在構建應用程序時可以發揮更多自己的創意。

在具有創意性的行業中工作意味著你可以向那些寫文章的作者身上學習到很多的東西。那些常常被推薦用于解決寫作困難的方法也是最好的寫作建議之一。

下面讓我來向你推薦“不完美初稿”的技巧 —— 因為它讓你成為效率更高的 “coder”。

”不完美初稿”的訣竅

“不完美初稿”的訣竅非常普遍，即使沒讀過網上那些各式各樣的關于寫作的博客，那你也可能早在英語課堂上就聽說過。

“不完美的初稿”的關鍵就是，即使你的初稿寫的非常的糟糕，但是你也只需完成初稿就夠了 —— 因為任何初稿都比什么都沒有的空白頁強。

編輯修整自己的作品要比從頭開始編寫要容易的多，所以，你應該立即嘗試地編寫一些內容(不管是什么內容都可以)只要能讓自己的代碼可以正常的工作。

換句話說，你今天要在午飯前寫完 100 行(有效)的不完美的代碼還是 0 行的完美代碼呢?

當然，最后的結果都是，你會用以上任何一種方式完成 50 行完美的代碼。但是編寫“不完美的初稿”能帶來心理上的優勢：你將在承受較少壓力的情況下獲得更大的成就感。

**你將會享受編碼的快樂!**難道還有什么比這個更重要?

我該如何開始創作一份初稿

我更傾向于以“簡單的初稿”為編碼的起點，因為“不完美的初稿”似乎是對我的編碼能力的一種否認。

你是否想成為一位寫“不良代碼”的“不良程序員”，因為你讀過有關編寫“不完美的初稿”的建議?

不，你想成為一名“成功的程序員”，編寫“出色的代碼”，因為你正在遵循從“簡單的初稿”開始編碼的技巧。

如果你曾經復制過一個代碼示例，然后對其進行了調整以供自己使用，那么實際上你已經學會了“簡單的初稿”的訣竅。

使用代碼示例時，你不可避免地要進行很多更改，但關鍵是首先要使代碼能夠工作，然后馬上對其進行改進。

無論你是編碼的新手還是專家，你都可以使用“簡單的初稿”的方法來完成任何的編程任務。

為什么“簡單的初稿”非常有用

當你編寫了有效的代碼時，你就會感到很有成就感，這使你擁有了更好的心態。簡單的代碼更有可能第一次編寫就能成功。

另外，簡單的代碼易于編寫，從而節省了時間。的確，它可能看起來重復又啰嗦，你機智的大腦也會懇求你去找出一個更簡潔、高效的“更好”的解決方案。

忽略它

訣竅是在有這些感覺時先喝點飲料，然后在追求簡單的道路中勇往直前。等到代碼生效后，你將立即對其進行重構 —— 在擁有能夠正常工作的版本之后，你就可以讓自己想法變得更加復雜。但是在這之前，請讓事情盡可能的簡單。

寫作教練August Birch把這個稱作“分步式寫作”：寫下整個內容，接著立即將它修改潤色，完善和修改不斷交替。

但是在這一點上，編程和寫作有所不同：因為代碼必須可以成功執行，所以開發人員都知道什么時候第一稿算是“足夠好”。當你的代碼正常工作時，這就是立即修改“簡單的初稿”的信號，并在進行下一步之前對其進行多次的完善。

對于任何只是學習編碼的人，這個方法都會提高兩項關鍵技能：編寫有效的代碼，并在不破壞正常運行的前提下改進代碼。

簡單的代碼示例

我最近通過領英平臺指導了一名初級工程師，他正為一個過于復雜的編碼挑戰而苦苦掙扎。盡管一旦你需要在真實的項目中實踐時，這樣的編碼挑戰就變得沒那么有用，但它是如何編寫“簡單的初稿”的一個很好的例子。

由于問題很復雜，所以他打算嘗試編寫一個復雜的解決方案。讓我們來看看這個挑戰：

“編寫一個函數 addWeirdStuff，該函數將 arrayTwo 中所有奇數的和與 arrayOne 中每個 10 以下的元素相加。

類似地，addWeirdStuff 還需要將 arrayTwo 中所有偶數之和與 arrayOne 中等于或大于 10 的那些元素相加。

另外：如果 arrayOne 中的元素與 arrayTwo 中大于 20 的元素相加時，還需要額外加上 1。

值得注意的是，就像在現實生活中一樣，他得到了不完整的需求說明：函數 addWeirdStuff 應該返回一個新數組，新數組包含來自 arrayOne 以及 arrayTwo 的項。

他最開始嘗試用一個 for 循環來解決這個問題，但是最終沒有成功。這是一項復雜的認知任務，對人的工作記憶(工作記憶是短期記憶的另一個稱呼)一定是個挑戰，而他對此一籌莫展。

這個人曾經為了解決另一個代碼難題聯系過我，因為他不小心將 return 語句放入復雜的 for 循環中。他還沒有準備好編寫簡潔的代碼。

我告訴他，他需要使用兩個單獨的 for 循環，為了簡單他應該使用 for…of 進行循環。以下是 JavaScript 代碼，以及為檢查他的代碼是否有效的測試：

View the raw code as a GitHub gist

這個代碼寫得很丑陋，效果很差，但是它可以用!并且它具有超強的可讀性，特別是對于那些剛剛開始努力學習基本概念的初學者來說。

下一步就是完善這個“簡單的初稿”。

重構時間

重構，不管你對它是愛是恨，單對于寫文章的作者們來說，就相當于一個編輯和修改的過程。在編程和其他類型的寫作中，如果是你自己編寫的文本(尤其是立即完成)，修改會變得更加容易。

首先使用簡單的語言來降低文本的復雜性，然后立即進行編輯修改。這個方法適用于所有類型的寫作，包括編碼。

我從上面的“簡單的初稿”進行了重構：

View the raw code as a GitHub gist

這仍然是一個具有挑戰性的問題，還有很多其他方法可以解決此問題，但是這個版本朝著正確方向邁出了重要的一步。

在此版本的初稿中，我加了 reduce 函數因為我更喜歡在代碼中使用函數式編程

記住：“完美是好的敵人。”這只是你的初稿，你可以再次編輯!那是分步式的過程。

我還將可讀性的優先級提高了，可讀性高于性能， 因為我在每個內部循環中使用了 .some()。這是 O(n2) 的雙層循環。對于小型的數組矩陣，這對性能沒什么影響，但是這樣的操作可能會讓你找不著工作。在我的下次一次重構的版本中，這也是不是重要的優化項。

我決定在完成“簡單的初稿”前，我又使用 .map() 進行了一輪變更：

View the raw code as a GitHub gist

這是一個 “被改善的初稿”。我將兩個 for…of 循環改成使用一次 .reduce()、一次 .some()、以及一次 .map()。我更喜歡這種編碼風格。但是老實說，我的初稿沒有什么“錯”，因為它是能用的，不是嗎?

現在，是切換編碼任務并決定明天再次審閱此段代碼的好時機。

應用于的真實編碼場景

在實際工作中，我們經常會收到混亂的需求說明以及最晚交付日期的壓力，特別是在使用新的 API 時。每個編碼人員有時都會想：“為什么這段代碼不能正常的工作?”

對于我指導的這個學生來說，他從無法將問題概念化到輕松解決問題，因為他是從簡單的for…of 循環開始的。得益于“簡單的初稿”，他沒有感到困難和挫敗，反而感到成功和成就。

如果你更有經驗，很自然的就能使用 .reduce()來解決問題，那就大膽試試吧!但是如果你需要查找語法，看看是否在不查找語法的情況，對代碼進行重構。因為在編碼階段你是可以一直對代碼進行修改的。

同樣地，如果你用的是 JavaScript，你可能希望能在在返回中增加類型檢查。這作為一個編碼挑戰，這不是必需的，可以第二天再考慮加上。

在現實世界的其他場景中，“簡單初稿”編碼方法的缺點在于你將頻繁進行 git commit：至少，在進行分步式開發時，需要頻繁提交初稿的每個版本。在完成初稿前，你可能已經提交了三四個工作版本。

如果在后續的工作中發現了問題，你會對之前的多次提交感到慶幸，因為你可以根據提交發現問題所在并找到解決方案。

另外，代碼的提交次數能給我超級大的驅動力，特別是當我遠程辦公時。

測試

根據你對測試的個人偏好，完全可以在寫代碼之前寫測試。只需遵循相同的方法即可：寫盡可能簡單的測試，然后在測試代碼可以正常工作后立即對其進行重構。

或者，像大多數程序員一樣，你可能更喜歡在有一段可以工作的代碼之后進行測試 —— 這也完全可以，在編寫代碼并將其重構一次或兩次之后，編寫一些簡單的測試，然后再對測試代碼進行重構。

我知道寫代碼的最快方法是完全執行以下操作：

1. 寫簡單的代碼
2. 寫簡單的測試
3. 用簡單的測試重構簡單的代碼
4. 重構簡單的測試

就個人而言，我發現專注于“不完美的初稿”(或我喜歡說的“簡單初稿”)使我更有可能先寫測試，因為我并不在乎寫的測試是否是完美的。

你甚至可以考慮將測試視為工作的“第二稿”，把測試任務推遲到明天。千萬別忘了測試，就當是一切都為了你自己，你的項目和你的公司。

結論

無論你是代碼新手，初級工程師還是專家，只要你不專注于完美，都將可以更快地寫更多代碼。從“簡單的初稿”開始，然后在代碼生效后立即對其進行修整。

從一位技術作家那里獲取經驗，該作家去年使用 10 種編程語言撰寫了 100,000 個有關 JavaScript 的文字 —— 這個寫作技巧對開發人員和作家均適用。

我對所有級別的程序員的真正建議是，你的初稿應該重復，甚至感覺像是“黑客”。首先忘記基本的編碼原則這篇文中所倡導的(不要自我重復)，然后再堅持最基本的編碼規則：

“KISS” (Keep It Simple, Stupid!)

一旦你做到了這一點，你就可以使你的代碼變得漂亮，但是如果你必須花費數小時的調試時間，那么一整天的工作就會花光了 —— 甚至無法讓那段代碼正常工作。相信我，我就經歷過!

而且，如果你只是在學習新的編程語言，開發工具或代碼庫，則此建議是強制性的、必選的。

編碼快樂!

原文地址：Why You Should Make Your Code as Simple as Possible

原文作者：Dr. Derek Austin ??

譯文出自：掘金翻譯計劃

本文永久鏈接：https://github.com/xitu/gold-miner/blob/master/article/2020/why-you-should-make-your-code-as-simple-as-possible.md

譯者：NieZhuZhu(彈鐵蛋同學)

校對者：Yuxiao Alisa Shi、flashhu、lsvih

本文轉載自微信公眾號「前端鐵蛋」，可以通過以下二維碼關注。轉載本文請聯系前端鐵蛋公眾號。