我一直在做一个不能被描述为“小”的项目(40个月),一个不能被定义为“小”的团队(约30人).我们一直在使用敏捷/ Scrum(1)的做法,以及健康剂量的TDD.
我不知道如果我从敏捷或TDD中选择了这一点,更可能是两者的组合,但是我现在显然是在调查的人群中看起来很糟糕.通过“调试”,我不是指更清晰的概念来确定系统可能出了什么问题,而是在Debug模式下运行系统的具体活动,逐步通过代码来找出否则不可忽视的细节.
由于我相当信服,这个问题不在于调试是否是不好的气味.相反,我想知道我如何能够说服我的队友.
认为调试模式是“标准”模式的人倾向于编写只能通过调试来理解的代码,这会导致大量时间浪费,因为每次在其他人开发的代码之上工作项目时,您都会浪费时间首先花费大量的时间来调试它(并且,因为没有涉及到bug)这个术语变得越来越荒谬) – 然后是孤岛危机.所以我很想说服我的一些队友,避免调试模式是一件好事(2).然而,由于他们习惯于生活在调试模式,他们似乎没有看到问题;对他们来说,在他们甚至开始做任何与他们的新项目相关的事情之前花费几个小时调试别人的代码是规范;他们没有看到任何错误.另外,由于他们花时间“弄清楚”,他们最终知道工作该领域的开发人员将可以使用,并将该项目传递给他们(导致另一个筒仓).
帮我制定一个计划,把他们从黑暗面！
提前致谢.
(1)也称为SCRUM(全帽).除此之外,我认为这个术语之后的星号必须被使用,因为 – 毫不奇怪 – 我们的组织调整了敏捷和Scrum过程,以适应所有相关利益相关方的需求.所以,说实话,我根本就不会假装这是100％的理论,但这是我的问题.
(2)是的,总是有时候我们必须进入调试模式,我不是绝对避免它,只是想尽量减少我们必须潜入的次数.
