如何编写优秀的代码

如何编写优秀的代码

来源

如何编写优秀的代码

XKCD

确保你的代码“足够好”

编写一段好的代码的第一步，也是最重要的一步，就是根本不要编写代码。

• 您是否验证过您的假设？
• 该代码的范围是什么？
• 它将如何影响现有代码？
• 有人已经写过这个代码吗？

能够回答这些问题是编写出优秀代码的基础。

与他人讨论

验证你选择的最佳方式是听取他人的意见。努力营造一个人们不惧挑战你的决定和理想的环境。

从正确的角度看，即使最坚固的墙也可能看起来很脆弱。

分解

既然你已经确信你的代码“可以写得好”，那么现在就该想想如何才能真正让它变得更好。首先，从 API 的角度思考，并尝试将你提出的代码分解成尽可能小的部分。

理解如何将任务分解成更小的部分，是我见过的初级程序员最头疼的事情。记住，你分解的代码块，别人才能帮你完成。如果把它当成一个整体，只会让你与团队格格不入。

代码设计阶段的初期应该尽量少涉及实现。你应该专注于处理需求和约束。花在实现上的时间往往是浪费，因为高层 API 的变更可能会使实现假设失效。以我个人的经验来看，在讨论实现时，先确定已经达成一致的 API，通常会让讨论更加顺利。

在编写之前先编写定义它的测试（辛辣且固执己见）

现在您已经知道如何分解代码了。请为每个确定的独立单元编写测试。在编写代码之前，为代码将要暴露的每个功能编写测试，这是 TDD（测试驱动开发）的标志性特征。目前已有大量关于 TDD 有效性的研究。虽然其中一些研究存在争议，但几乎所有研究都报告了使用 TDD 后 bug 数量有所改善。

补充：我原本声称 TDD 可以减少 40%-80% 的 bug。在收到Reddit上的评论后，我意识到这种说法本身就存在数据偏差。我在下面附上了一张研究结果的图片，方便大家自行判断。我还附上了作者之前发表的一段话。

研究结果有时会引起争议（在学术研究中尤其如此）。考虑到测量结果难以比较，以及难以将TDD的影响与许多其他背景变量区分开来，这并不奇怪。此外，许多研究缺乏统计检验能力，无法进行普遍性分析。因此，我们建议读者结合每项研究的具体背景和环境来考量实证研究结果。

2005 年的一项研究发现，使用 TDD 意味着需要编写更多测试，反过来，编写更多测试的程序员往往效率更高。关于代码质量以及 TDD 与生产力之间是否存在更直接关联的假设尚无定论。关于代码质量以及 TDD 与生产力之间是否存在更直接关联的假设尚无定论。

来源：维基百科

我相信测试驱动开发会迫使你首先站在用户的角度，这将产生一组更实用、更自然的 API。

抵制同时处理多个任务的诱惑。你应该先为代码的单个单元编写失败测试，​​然后再编写该测试的实现。这样可以有效地验证你的设计，并在向代码库添加代码时保持测试覆盖率。

保持代码一致性

不同开发者的个人风格和偏好会有所不同。但代码一致性不应该有所不同。变量和声明的命名约定应该一致且可预测。如果使用制表符，则应在所有地方都使用制表符。如果使用空格，则应在所有地方都使用空格。

许多初级开发人员会纠结于每个选择的细微差别。实际上，更重要的是你的选择是否可靠。乍一看，这似乎是一项相对较小的任务，但一致性的意义远不止于制表符和空格。

你的代码逻辑也需要保持一致。为什么你map在这里用了“a”，for each在那里用了“a”？为什么你var在某些地方用了“but”，let而const在其他地方用了“but”？可预测性是程序员（或者说一般人）最难发现的特质之一，也是最宝贵的特质之一。

作为一名程序员，你的价值取决于你的“最大潜在价值”乘以你的“预计风险”。没有可靠性，质量就毫无意义。

回顾一下

来源

如果代码进入主分支，就应该进行审查。为了使审查有益，作者需要真正认识到审查过程的价值。

你这一生永远不可能知道一切。

优秀的程序员编写了出色的代码但却没有得到审查。

优秀的程序员会编写优秀的代码，但会经过严格的审查过程。

你应该为生活中方方面面的失败负责，包括编程。错误难免会犯，而大多数情况下，只需要另一双眼睛就能阻止它们。

发货

恭喜，你现在已经写出了一段优秀的代码。没有这个过程也有可能写出优秀的代码，但没有这个过程，你不可能“总是写出优秀的代码”。

发货后，请记得与您的团队沟通您所完成的工作，这可能会解除对某人的阻止。

不要想太多

这里的每条规则都应该谨慎对待。一个只有两行代码的内部提交README真的需要审核吗？

力求最佳实践，但要保持务实和理性，不要设计那些根本不需要设计的东西。你最重要的工具是你的直觉。规则的存在不是为了阻碍你，而是为了在你不顺从（而且你也不会顺从）的时候保持一致和可靠。

我的博客