原文地址：https://hackernoon.com/few-si...嗨，我从事程序员工作超过15年，并使用许多不同的语言、范例、框架和其他垃圾。我想与您分享我编写好的代码的规则。优化VS可读性去他妈的优化总是编写易于阅读和开发人员理解的代码。因为花费在难以阅读的代码上的时间和资源将远远高于优化所能获得的。如果需要做优化，那就做成像DI一样自成体系的模块，测试覆盖率100%，至少一年不碰。架构优先我看到很多人说“我们需要快速做事，我们没有时间研究架构”。大约99%的人都因为这样想而出了大问题。编写代码而不考虑其架构就像梦想您的愿望而没有计划实现它们一样毫无用处。在编写第一行代码之前，你应该了解它会做什么，如何使用，模块、服务如何相互协作，它会有什么结构，它会如何测试和调试，以及它会如何运行。被更新。测试覆盖率测试很好，但它们并不总是对项目负担得起和有意义。什么时候需要测试：写模块的时候，微服务至少一个月不碰。当您编写开源代码时。当你编写核心代码或涉及金融渠道的代码时。当您有代码更新时更新您的测试资源。当您不需要测试时：当您是一家初创公司时。当您有小团队并且代码更改很快时。当你编写脚本时，你可以简单地通过输出它们来手动测试它们。请记住，经过严格测试的代码可能比未经测试的代码更有害。保持简单，超级简单，不要编写复杂的代码。它越简单，它可能有的错误就越少，调试它们所需的时间也就越少。代码应该只做它需要的事情，没有太多的抽象和其他OOP垃圾（尤其是涉及Java开发人员）+20%的东西可能需要在未来以一种简单的方式更新。评论评论表明您的代码不够好。好的代码应该无需一行注释也能看懂。但是如何为新开发者节省时间呢？-编写简单的内联文档，描述方法的工作原理和工作原理。这将节省大量的时间来理解，甚至更多——它会给人们更多的机会来想出更好的方法来实现它。这将是全球代码文档的良好开端。硬耦合VS次要耦合始终尝试使用微服务架构。单体软件可以比微服务软件运行得更快，但仅限于在一台服务器的环境中。微服务允许您不仅在许多服务器上有效地分发软件，有时甚至在一台机器上（我的意思是通过进程分发）。代码审查代码审查可以是好也可以是坏。只有当你的开发人员知道95%的代码，他们可以监控所有更新而不会浪费很多时间时，你才能组织代码审查。在其他情况下，这将非常耗时，而且每个人都会讨厌它。这部分有很多问题，因此请更深入地描述这一点。许多人认为代码审查是教新手或处理代码不同部分的队友的好方法。但代码审查的主要目标是保持代码质量，而不是教学。假设您的团队编写代码来控制核反应堆或太空火箭发动机的冷却系统。你在非常困难的逻辑上犯了巨大的错误，然后你给这个代码审查一个新人。您认为发生事故的风险如何？-我的练习率超过70%。一个好的团队，就是每个人都有自己的角色，各司其职。如果有人想看懂另一段代码，那就去找负责人请教。你不可能无所不知，理解一小段代码比理解一切要好。重构没用在我的职业生涯中，我多次听到“别担心，我们稍后会重构它”。将来，这可能会导致大量技术债务或从头开始删除所有代码和编写。因此，除非您有足够的钱从头开始多次开发您的软件，否则不要欠债。不要在累了或者心情不好的时候写代码。当开发人员感到无聊时，他们会制造2到5倍或更多的错误。所以工作更多是非常糟糕的做法。这就是为什么越来越多的国家正在考虑实行6小时工作制，其中一些国家已经实行了。脑力劳动不同于使用二头肌。不要一次全部编写-进行开发迭代在编写代码之前分析并预测您的客户/客户真正需要什么，然后选择您可以在短期内高质量开发的MVF（最有价值的功能）。使用这样的迭代来部署质量更新，而不是浪费时间和资源来满足不合理的欲望和质量牺牲。自动化VS手动自动化从长远来看是100%成功的。因此，如果您有资源来实现自动化，那么是时候去做了。你可能会想“只需要5分钟，我为什么要自动化呢？”但是让我计算一下。例如，这是5个开发人员的日常任务。5分钟5天21天*12个月=6300分钟=105小时=13.125天~5250$。如果你有40000名员工，这将花费多少？出去学习新的爱好区分工作可以提高心智能力并提供新的想法。所以，暂停你现在的工作，出去呼吸一下新鲜空气，和朋友聊天，弹吉他等等。ps：莫春，春装准备好了，五六个状元，六七个男生，沐浴伊风舞，歌唱归来。------《论语.先进》。在空闲时间学习新事物当人们停止学习时，他们就会开始倒退。
