Answers:
在更改代码之前编写测试。
如果您建议的更改是修复错误，请首先通过演示该错误使测试失败。修复错误后，请确保它通过。如果您随后编写了测试，并且只通过了测试，那么您将无法确保首先正确地测试了该错误。
如果您建议的更改是更改现有功能或添加功能，请编写一些测试以确保对要更改的代码区域有良好的覆盖。在开始更改代码之前，请确保这些测试通过，并在完成后仍通过。
遵循技术指导中的技术建议；这是好东西。我的答案更多是关于态度。
对每个开发人员偶尔会犯的那种错误感到沮丧，这是荒谬的，并且不能帮助您将来不再犯这种错误。当您坐在那里时感觉很不好，但是构造仍然坏了，您知道吗？然后您的工作就是避免出错，我知道每天早上起床都是令人兴奋的冒险，对吧？
我听说过一些公司，检查破损的代码会引起公众羞辱。我什至无法避免那种会导致这种行为的扭曲、,脚的男孩，初中级思维。对于团队负责人或经理而言，几乎没有什么事与愿违的。
所以不要打自己。我们都做到了。我可能每周会花半天时间来解决一些愚蠢的错误，而且我已经（咳嗽）很长时间了。那就是编写代码的样子-您一直在不断地努力应对自己的不足之处。使专业人士成为职业的原因，不是永不犯错误（有时包括大错误）的神话般的品质，而是他们如何应对所犯的错误。
如果我可以向与我合作的每个开发人员灌输一种口头禅，那就是：您不是您的代码。您编写代码。您会尽可能高效地编写它。那你回家吧 如果您将自己的价值或自我价值与代码质量等同起来，那么您就迷失了真正的身份。