[[374545]]

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

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

軟件開發(fā)人員從事著最具創(chuàng)意的工程類型的工作。畢竟，與構(gòu)建橋梁的土木工程師相比，軟件工程師在構(gòu)建應(yīng)用程序時可以發(fā)揮更多自己的創(chuàng)意。

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

下面讓我來向你推薦“不完美初稿”的技巧 —— 因?yàn)樗屇愠蔀樾矢叩?“coder”。

”不完美初稿”的訣竅

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

“不完美的初稿”的關(guān)鍵就是，即使你的初稿寫的非常的糟糕，但是你也只需完成初稿就夠了 —— 因?yàn)槿魏纬醺宥急仁裁炊紱]有的空白頁強(qiáng)。

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

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

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

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

我該如何開始創(chuàng)作一份初稿

我更傾向于以“簡單的初稿”為編碼的起點(diǎn)，因?yàn)?ldquo;不完美的初稿”似乎是對我的編碼能力的一種否認(rèn)。

你是否想成為一位寫“不良代碼”的“不良程序員”，因?yàn)槟阕x過有關(guān)編寫“不完美的初稿”的建議?

不，你想成為一名“成功的程序員”，編寫“出色的代碼”，因?yàn)槟阏谧裱瓘?ldquo;簡單的初稿”開始編碼的技巧。

如果你曾經(jīng)復(fù)制過一個代碼示例，然后對其進(jìn)行了調(diào)整以供自己使用，那么實(shí)際上你已經(jīng)學(xué)會了“簡單的初稿”的訣竅。

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

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

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

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

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

忽略它

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

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

但是在這一點(diǎn)上，編程和寫作有所不同：因?yàn)榇a必須可以成功執(zhí)行，所以開發(fā)人員都知道什么時候第一稿算是“足夠好”。當(dāng)你的代碼正常工作時，這就是立即修改“簡單的初稿”的信號，并在進(jìn)行下一步之前對其進(jìn)行多次的完善。

對于任何只是學(xué)習(xí)編碼的人，這個方法都會提高兩項(xiàng)關(guān)鍵技能：編寫有效的代碼，并在不破壞正常運(yùn)行的前提下改進(jìn)代碼。

簡單的代碼示例

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

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

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

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

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

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

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

這個人曾經(jīng)為了解決另一個代碼難題聯(lián)系過我，因?yàn)樗恍⌒膶?return 語句放入復(fù)雜的 for 循環(huán)中。他還沒有準(zhǔn)備好編寫簡潔的代碼。

我告訴他，他需要使用兩個單獨(dú)的 for 循環(huán)，為了簡單他應(yīng)該使用 for…of 進(jìn)行循環(huán)。以下是 JavaScript 代碼，以及為檢查他的代碼是否有效的測試：

View the raw code as a GitHub gist

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

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

重構(gòu)時間

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

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

我從上面的“簡單的初稿”進(jìn)行了重構(gòu)：

View the raw code as a GitHub gist

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

在此版本的初稿中，我加了 reduce 函數(shù)因?yàn)槲腋矚g在代碼中使用函數(shù)式編程

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

我還將可讀性的優(yōu)先級提高了，可讀性高于性能， 因?yàn)槲以诿總€內(nèi)部循環(huán)中使用了 .some()。這是 O(n2) 的雙層循環(huán)。對于小型的數(shù)組矩陣，這對性能沒什么影響，但是這樣的操作可能會讓你找不著工作。在我的下次一次重構(gòu)的版本中，這也是不是重要的優(yōu)化項(xiàng)。

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

View the raw code as a GitHub gist

這是一個 “被改善的初稿”。我將兩個 for…of 循環(huán)改成使用一次 .reduce()、一次 .some()、以及一次 .map()。我更喜歡這種編碼風(fēng)格。但是老實(shí)說，我的初稿沒有什么“錯”，因?yàn)樗悄苡玫模皇菃?

現(xiàn)在，是切換編碼任務(wù)并決定明天再次審閱此段代碼的好時機(jī)。

應(yīng)用于的真實(shí)編碼場景

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

對于我指導(dǎo)的這個學(xué)生來說，他從無法將問題概念化到輕松解決問題，因?yàn)樗菑暮唵蔚膄or…of 循環(huán)開始的。得益于“簡單的初稿”，他沒有感到困難和挫敗，反而感到成功和成就。

如果你更有經(jīng)驗(yàn)，很自然的就能使用 .reduce()來解決問題，那就大膽試試吧!但是如果你需要查找語法，看看是否在不查找語法的情況，對代碼進(jìn)行重構(gòu)。因?yàn)樵诰幋a階段你是可以一直對代碼進(jìn)行修改的。

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

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

如果在后續(xù)的工作中發(fā)現(xiàn)了問題，你會對之前的多次提交感到慶幸，因?yàn)槟憧梢愿鶕?jù)提交發(fā)現(xiàn)問題所在并找到解決方案。

另外，代碼的提交次數(shù)能給我超級大的驅(qū)動力，特別是當(dāng)我遠(yuǎn)程辦公時。

測試

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

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

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

1. 寫簡單的代碼
2. 寫簡單的測試
3. 用簡單的測試重構(gòu)簡單的代碼
4. 重構(gòu)簡單的測試

就個人而言，我發(fā)現(xiàn)專注于“不完美的初稿”(或我喜歡說的“簡單初稿”)使我更有可能先寫測試，因?yàn)槲也⒉辉诤鯇懙臏y試是否是完美的。

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

結(jié)論

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

從一位技術(shù)作家那里獲取經(jīng)驗(yàn)，該作家去年使用 10 種編程語言撰寫了 100,000 個有關(guān) JavaScript 的文字 —— 這個寫作技巧對開發(fā)人員和作家均適用。

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

“KISS” (Keep It Simple, Stupid!)

一旦你做到了這一點(diǎn)，你就可以使你的代碼變得漂亮，但是如果你必須花費(fèi)數(shù)小時的調(diào)試時間，那么一整天的工作就會花光了 —— 甚至無法讓那段代碼正常工作。相信我，我就經(jīng)歷過!

而且，如果你只是在學(xué)習(xí)新的編程語言，開發(fā)工具或代碼庫，則此建議是強(qiáng)制性的、必選的。

編碼快樂!

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

原文作者：Dr. Derek Austin ??

譯文出自：掘金翻譯計(jì)劃

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

譯者：NieZhuZhu(彈鐵蛋同學(xué))

校對者：Yuxiao Alisa Shi、flashhu、lsvih

本文轉(zhuǎn)載自微信公眾號「前端鐵蛋」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系前端鐵蛋公眾號。