调试是一种不好的气味 – 如何说服他们?

前端之家收集整理的这篇文章主要介绍了调试是一种不好的气味 – 如何说服他们?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我一直在做一个不能被描述为“小”的项目(40个月),一个不能被定义为“小”的团队(约30人).我们一直在使用敏捷/ Scrum(1)的做法,以及健康剂量的TDD.

我不知道如果我从敏捷或TDD中选择了这一点,更可能是两者的组合,但是我现在显然是在调查的人群中看起来很糟糕.通过“调试”,我不是指更清晰的概念来确定系统可能出了什么问题,而是在Debug模式下运行系统的具体活动,逐步通过代码来找出否则不可忽视的细节.

由于我相当信服,这个问题不在于调试是否是不好的气味.相反,我想知道我如何能够说服我的队友.

认为调试模式是“标准”模式的人倾向于编写只能通过调试来理解的代码,这会导致大量时间浪费,因为每次在其他人开发的代码之上工作项目时,您都会浪费时间首先花费大量的时间来调试它(并且,因为没有涉及到bug)这个术语变得越来越荒谬) – 然后是孤岛危机.所以我很想说服我的一些队友,避免调试模式是一件好事(2).然而,由于他们习惯于生活在调试模式,他们似乎没有看到问题;对他们来说,在他们甚至开始做任何与他们的新项目相关的事情之前花费几个小时调试别人的代码是规范;他们没有看到任何错误.另外,由于他们花时间“弄清楚”,他们最终知道工作该领域的开发人员将可以使用,并将该项目传递给他们(导致另一个筒仓).

帮我制定一个计划,把他们从黑暗面!

提前致谢.

(1)也称为SCRUM(全帽).除此之外,我认为这个术语之后的星号必须被使用,因为 – 毫不奇怪 – 我们的组织调整了敏捷和Scrum过程,以适应所有相关利益相关方的需求.所以,说实话,我根本就不会假装这是100%的理论,但这是我的问题.

(2)是的,总是有时候我们必须进入调试模式,我不是绝对避免它,只是想尽量减少我们必须潜入的次数.

如果你想说服你的同事,你的编程实践更好,首先要表现出你的生产力,你比他们更有效,至少对于一些任务.然后他们会相信你,当你解释你如何做得这么多.

有时也更容易专注于具体的东西.你的同事们甚至会说“代码气味”吗?也许您可以专注于“当ABC模块失败时,会永远调试它;使用技术XYZ要快得多,这里让我演示一下.”然后,你可以提到你的基本原理,这是调试器是一个有用的工具,但通常还有其他更有用的工具.

猜你在找的设计模式相关文章