首先抱歉无代码问题，但我想澄清一件事。
我有一个团队的高级开发人员正在积极推动代码质量 - 合并请求审核，没有糟糕的代码和类似的。但是团队中的大多数其他人都有 - 做好心态。我作为一个商业人士，我根本不检查代码，但如果我没有那个关心质量的人 - 在我看来我们会在某些时候遇到一些沉重的重构周期。
但当然，谨慎对待质量有一个缺点 - 这需要时间。当我们需要根据业务需求的变化进行调整时，我们可能需要抛出许多漂亮的代码。
两个问题：a）您如何保持产品质量？你用了什么做法？ b）对代码质量的关注程度在哪里（不是太少而不是太多）？
答案 0 :(得分：2)
代码质量非常重要，无论您是否开发敏捷。质量改进需要额外的时间，这是绝对正确的。大多数人失败是因为他们花时间在较大的块（“重构项目”）中或多或少地在任意位置清理代码，目的是尽可能减少质量问题的数量。
我建议使用的过程是遵循 boy-scout规则，始终保持更改的代码比以前更清晰（更好）。这意味着无论何时更改功能，过程，方法或其他代码单元，都要修复其中的质量问题。优点是你已经理解了代码（因为你不得不改变它）并且它将被测试（因为你需要测试你原来的变化）。这意味着质量改进的额外努力（添加评论，改进标识符，删除冗余，......）非常低。此外，您只是在改进您正在使用的代码，并且不会浪费时间来改进从未接触过的代码。
遵循童子军规则确保质量不会降低，而是随着时间的推移稳步增加。这也是“关怀”的合理水平。我写了更多关于这个here的文章。此外，您需要一个高质量的分析工具，如Teamscale，可以可靠地区分遗留问题，新问题和您最近更改的代码中的问题。
答案 1 :(得分：0)
获取并实施一个良好的单元测试框架，并通过自动化集成测试进行备份。
至于敏捷我发现早上10分钟的scrums是有用的，但冲刺结束时间往往很长。
答案 2 :(得分：0)
我使用Sonar Qube我们用于静态代码分析的工具获得了很好的体验。所以我们可以跟踪 我们的代码库中的代码气味等。另一点是，可以通过短跑来解决问题！也可以使用IDE集成！