共计 4153 个字符，预计需要花费 11 分钟才能阅读完成。
编程很像写作 —— 你应该从一个能用的“不完满的初稿”开始，再通过两三次批改，一一解决初稿中存在的问题。
工程师们必定会讥笑本人竟然被轻率地比作了”作家“—— 然而明天早上的文档又是谁写的呢？你不是在“写代码”吗?
软件开发人员从事着最具创意的工程类型的工作。毕竟，与构建桥梁的土木工程师相比，软件工程师在构建应用程序时能够施展更多本人的创意。
在具备创意性的行业中工作意味着你能够向那些写文章的作者身上学习到很多的货色。那些经常被举荐用于解决写作艰难的办法也是最好的写作倡议之一。
上面让我来向你举荐“不完满初稿”的技巧 —— 因为它让你成为效率更高的“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 代码，以及为查看他的代码是否无效的测试：
这个代码写得很俊俏，成果很差，然而它能够用！并且它具备超强的可读性，特地是对于那些刚刚开始努力学习基本概念的初学者来说。
下一步就是欠缺这个“简略的初稿”。
重构工夫
重构，不论你对它是爱是恨，单对于写文章的作者们来说，就相当于一个编辑和批改的过程。在编程和其余类型的写作中，如果是你本人编写的文本（尤其是立刻实现），批改会变得更加容易。
首先应用简略的语言来升高文本的复杂性，而后立刻进行编辑批改。这个办法实用于所有类型的写作，包含编码。
我从下面的“简略的初稿”进行了重构：
这依然是一个具备挑战性的问题，还有很多其余办法能够解决此问题，然而这个版本朝着正确方向迈出了重要的一步。
在此版本的初稿中，我加了 reduce 函数因为我更喜爱在代码中应用函数式编程
记住：“完满是好的敌人。”这只是你的初稿，你能够再次编辑！那是分步式的过程。
我还将可读性的优先级进步了，可读性高于性能，因为我在每个外部循环中应用了 .some()。这是 O(n²) 的双层循环。对于小型的数组矩阵，这对性能没什么影响，然而这样的操作可能会让你找不着工作。在我的下次一次重构的版本中，这也是不是重要的优化项。
我决定在实现“简略的初稿”前，我又应用 .map() 进行了一轮变更：
这是一个“被改善的初稿”。我将两个 for…of 循环改成应用一次 .reduce()、一次 .some()、以及一次 .map()。我更喜爱这种编码格调。然而诚实说，我的初稿没有什么“错”，因为它是能用的，不是吗？
当初，是切换编码工作并决定今天再次审阅此段代码的好时机。
利用于的实在编码场景
在理论工作中，咱们常常会收到凌乱的需要阐明以及最晚交付日期的压力，特地是在应用新的 API 时。每个编码人员有时都会想：“为什么这段代码不能失常的工作？”
对于我领导的这个学生来说，他从无奈将问题概念化到轻松解决问题，因为他是从简略的 for…of 循环开始的。得益于“简略的初稿”，他没有感到艰难和挫败，反而感到胜利和成就。
如果你更有教训，很天然的就能应用 .reduce() 来解决问题，那就大胆试试吧！然而如果你须要查找语法，看看是否在不查找语法的状况，对代码进行重构。因为在编码阶段你是能够始终对代码进行批改的。
同样地，如果你用的是 JavaScript，你可能心愿能在在返回中减少类型查看。这作为一个编码挑战，这不是必须的，能够第二天再思考加上。
在事实世界的其余场景中，“简略初稿”编码方法的毛病在于你将频繁进行 git commit：至多，在进行分步式开发时，须要频繁提交初稿的每个版本。在实现初稿前，你可能曾经提交了三四个工作版本。
如果在后续的工作中发现了问题，你会对之前的屡次提交感到庆幸，因为你能够依据提交发现问题所在并找到解决方案。
另外，代码的提交次数能给我超级大的驱动力，特地是当我近程办公时。
测试
依据你对测试的集体偏好，齐全能够在写代码之前写测试。只需遵循雷同的办法即可：写尽可能简略的测试，而后在测试代码能够失常工作后立刻对其进行重构。
或者，像大多数程序员一样，你可能更喜爱在有一段能够工作的代码之后进行测试 —— 这也齐全能够，在编写代码并将其重构一次或两次之后，编写一些简略的测试，而后再对测试代码进行重构。
我晓得写代码的最快办法是齐全执行以下操作：
- 写简略的代码
- 写简略的测试
- 用简略的测试重构简略的代码
- 重构简略的测试
就集体而言，我发现专一于“不完满的初稿”（或我喜爱说的“简略初稿”）使我更有可能先写测试，因为我并不在乎写的测试是否是完满的。
你甚至能够思考将测试视为工作的“第二稿”，把测试工作推延到今天。千万别忘了测试，就当是所有都为了你本人，你的我的项目和你的公司。
论断
无论你是代码老手，高级工程师还是专家，只有你不专一于完满，都将能够更快地写更多代码。从“简略的初稿”开始，而后在代码失效后立刻对其进行休整。
从一位技术作家那里获取教训，该作家去年应用 10 种编程语言撰写了 100,000 个无关 JavaScript 的文字 —— 这个写作技巧对开发人员和作家均实用。
我对所有级别的程序员的真正倡议是，你的初稿应该反复，甚至感觉像是“黑客”。首先遗记根本的编码准则这篇文中所提倡的（不要自我反复），而后再保持最根本的编码规定：
“KISS”(Keep It Simple, Stupid!)
一旦你做到了这一点，你就能够使你的代码变得丑陋，然而如果你必须破费数小时的调试工夫，那么一整天的工作就会花光了 —— 甚至无奈让那段代码失常工作。 置信我，我就经验过！
而且，如果你只是在学习新的编程语言，开发工具或代码库，则此倡议是强制性的、必选的。
编码高兴！
???? 明天的文章分享就到这里啦，如果喜爱这篇文章的话请点赞、Star、关注我（公众号：前端铁蛋）吧 ????
- 原文地址：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