良好的习惯，高质量的代码
“别指望每天都有动力出去大展拳脚。你不会有的。别指望动力，要靠自律。”——
乔克·威林克
我超爱这句话，每次感到懒散疲惫，不想早起、不想锻炼、不想完成Udemy上的课程、不想洗碗或者不想做任何事的时候，我都会想起它。
我热爱攀岩，恨不得每天都去，但是汗流浃背、尖叫呐喊，还有全身肌肉酸痛的那种感觉，真是太难受了！不过，锻炼真的很重要！一旦养成习惯，你就能从中受益匪浅。
在编程中，我们编写简洁、高质量代码的动力可能来自于刚刚学习了一个新概念，或者发现了一个新的很酷的技巧，又或者是因为刚刚开始使用一个全新的代码库，或者刚刚加入了一个新的团队或项目。
或者或者或者，如果如果如果。
事实是，随着时间的推移，我们可能会感到厌倦，变得马虎。然后，我们就不再在意这种方法中是否存在拼写错误，或者是否重复了十次相同或相似的内容。
复制粘贴更方便，任务完成！
有时候，我们可能有一些合理的理由或借口，使我们有理由不编写高质量的代码：
送货！送货！送货！
或许这些说法都对，但我仍然坚信编写高质量代码是一种好习惯，而且像大多数习惯一样，它需要自律和投入。你必须下定决心，想办法强迫自己去做。
这样它就会成为一种习惯，你会发现自己甚至不用思考就能写出好代码。恰恰相反，编写粗糙的代码会让你感觉非常奇怪和困难。
你有没有打开集成开发环境（IDE）时想过：
哦——我赶时间——咱们写点烂代码吧——但一定要把事情做完。
或者
好，冲刺计划已经安排好了，现在我有充足的时间来好好设计和实现各项功能。让我们慢慢来，精益求精。哦耶！
我不这么认为。但如果我们缺乏自律和正确的态度，这两种想法都可能潜藏在我们的编码风格中。
如果编写好的代码需要花费我们很多精力，那么我们一有机会就会放弃。
但那只是个原型，代码不一定要美观！
最近我们开发了一个原型，大家都对这个新项目感到非常兴奋，我们想快速迭代，结果写了很多混乱的代码。
但是，混乱的代码到底是什么意思呢？
在原型开发阶段，速度比质量更重要。
目标是快速迭代，而在迭代过程中，你会不断地修改功能和删除代码。
放弃一些非常好的想法可能会令人沮丧，但这就是现实，关键就在于不断尝试，向客户展示，然后迭代。某个想法（以及与之配套的代码）可能很棒，但却不适合项目，客户不喜欢，或者他们改变了主意，修改了需求。
记住这一点，你就可以走一些捷径：
- 提交之前，你并没有修复所有的代码检查错误。
- 你允许一些（或很多）重复内容，
- 你将某些值或整个数据提供程序硬编码到代码中，
- 你可以跳过为 React 组件编写所有 PropTypes 的步骤。
- 您可以直接对组件进行样式设置等等。
很有可能所有东西最终都会被扔掉！
这一切都没问题，但你也要记住，有些代码不会被丢弃。多年来，我从未见过哪个原型仅仅被用作概念验证。一旦概念获得批准，大多数情况下，你会开始在其基础上构建其他功能。
因此，原型代码库的许多部分最终都会保留在最终项目中，所以这些代码越好，你就能越快地重构或扩展它们。此外，这些代码在某种程度上会成为起点——标准——所有后续开发人员编写代码的参考。
所以，即使是原型，也不要因为它是原型就写出糟糕、马虎的代码。要自律，坚持编写高质量的代码，有意识地选择一些捷径，但不要让“没时间”这个借口蒙蔽了你的双眼。
但我必须抓紧时间！
另一个不该写劣质代码的原因是：没错，你需要快速交付，但这并不意味着你必须赶工。
大多数情况下，开发团队都会参与预估某个功能何时能够完成。因此，交付日期并非总是由上级强制规定的。你有机会争取足够的时间，避免压力过大，也避免被迫编写糟糕的代码。
在我的职业生涯中，我发现很多同事在代码审查过程中都会说：
我知道这段代码很糟糕，但我们会尽快重构它，等我们攒够钱来偿还技术债务后就会进行。
这种情况很少发生。
利益相关者总是会优先考虑功能（功能性需求），而不是质量/重构/非功能性需求。
从表面上看，应用程序运行正常，为什么要改变它呢？
为什么要把时间浪费在华而不实、对最终用户毫无益处的功能上，而不是投资于能够带来新用户或更多收益的新功能呢？
但
如果没有定期且积极的重构，我们就无法编写出合理且易于维护的代码。——摘自《编码恐怖》
如果没有纪律，我们总能找到各种借口。
你必须妥善规划你的工单，有时甚至需要争取一个准确合理的预估/交付日期。
你必须与同事和项目经理分享“完成”的定义，并将其纳入功能单元测试和代码质量考量范围。
你必须强迫自己进行所有这些练习。有些练习可能会让你感到不舒服、困难，或者枯燥乏味，但只要坚持，它就会成为一种好习惯。
