我不知道如果我从敏捷或TDD中选择了这一点,更可能是两者的组合,但是我现在显然是在调查的人群中看起来很糟糕.通过“调试”,我不是指更清晰的概念来确定系统可能出了什么问题,而是在Debug模式下运行系统的具体活动,逐步通过代码来找出否则不可忽视的细节.
由于我相当信服,这个问题不在于调试是否是不好的气味.相反,我想知道我如何能够说服我的队友.
认为调试模式是“标准”模式的人倾向于编写只能通过调试来理解的代码,这会导致大量时间浪费,因为每次在其他人开发的代码之上工作项目时,您都会浪费时间首先花费大量的时间来调试它(并且,因为没有涉及到bug)这个术语变得越来越荒谬) – 然后是孤岛危机.所以我很想说服我的一些队友,避免调试模式是一件好事(2).然而,由于他们习惯于生活在调试模式,他们似乎没有看到问题;对他们来说,在他们甚至开始做任何与他们的新项目相关的事情之前花费几个小时调试别人的代码是规范;他们没有看到任何错误.另外,由于他们花时间“弄清楚”,他们最终知道工作该领域的开发人员将可以使用,并将该项目传递给他们(导致另一个筒仓).
帮我制定一个计划,把他们从黑暗面！
提前致谢.
(1)也称为SCRUM(全帽).除此之外,我认为这个术语之后的星号必须被使用,因为 – 毫不奇怪 – 我们的组织调整了敏捷和Scrum过程,以适应所有相关利益相关方的需求.所以,说实话,我根本就不会假装这是100％的理论,但这是我的问题.
(2)是的,总是有时候我们必须进入调试模式,我不是绝对避免它,只是想尽量减少我们必须潜入的次数.
有时也更容易专注于具体的东西.你的同事们甚至会说“代码气味”吗？也许您可以专注于“当ABC模块失败时,会永远调试它;使用技术XYZ要快得多,这里让我演示一下.”然后,你可以提到你的基本原理,这是调试器是一个有用的工具,但通常还有其他更有用的工具.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
