Mic*_*fik 26 c++ maintainability refactoring scrum unit-testing
我们的代码很糟糕.实际上,让我澄清一下.我们的旧代码很糟糕.它很难调试,并且充满了很少人理解甚至记住的抽象概念.就在昨天,我花了一个小时在一个我工作了一年多的地方进行调试,发现自己在想,"哇,这真的很痛苦." 这不是任何人的错 - 我确信这一切最初都是完全合理的.最糟糕的部分通常是它只是工作...如果你不要求它做任何超出其舒适区域的事情.
我们的新代码非常好.我想我们在那里做了很多好事.它清晰,一致,(希望)可维护.我们有一台运行用于持续集成的Hudson服务器,我们已经开始使用单元测试套件了.问题是我们的管理层专注于编写新代码.没有时间给Old Code(甚至旧的新代码)提供它迫切需要的TLC.在任何特定时刻,我们的scrum积压(针对六个开发人员)有大约140个项目和大约十几个缺陷.这些数字并没有太大变化.我们正在以尽可能快的速度添加东西.
那么我该怎么做才能避免马德里调试会话在Old Code的深处陷入困境呢？每个sprint都充满了新的发展和showstopper缺陷.特别...
Dav*_*ley 22
您的管理层可能专注于将工作功能纳入产品,并使其保持正常运行.在这种情况下,你需要做一个商业案例来重构旧的东西,因为通过X投入的时间和精力,你可以减少Y在Z期间的必要维护时间.或者你的管理层可能从根本上一无所知(这种情况发生,但不像大多数开发人员似乎认为的那样,在这种情况下你永远不会获得许可.
您需要查看业务观点.对于最终用户来说,代码是丑陋的还是优雅的只是软件的作用并不重要.不良代码的成本是潜在的不可靠性和更改它的额外困难; 它对程序员造成的情绪困扰很少被考虑.
如果你无法获得进入和重构的许可,你可以随时自己尝试一下.每当你修复一个bug时,做一点改写以使事情更清楚.这可能会比最小可能的修复更快,特别是在验证代码现在有效时.即使不是这样,通常也可以花一点时间修复bug而不会遇到麻烦.只是不要被带走.
如果你每次进去都可以让代码稍微好一些,那么你会感觉好多了.
bba*_*our 12
我可能会去找我的机械师,我们早上会举行一次小型的站立会议:
我告诉他我希望我的车轮对齐,我的轮胎旋转,我的油更换了.我提到"哦,顺便说一下,我的刹车在路上感觉有点软.可能[他]看看他们吗？我多久能把车开回来,因为我需要回去工作？"
他把头砸到我的车下面,弹回来说我的刹车油泄漏并开始失灵.他将需要一部分将于上午10:30到达.他的男人不会在午餐前完成,但我应该在下午1:30左右将车开回来.他已经预定了,所以他今天无法做任何其他事情,我将不得不预约另一个.
我问他是否可以做其他事情,我回来做刹车.他告诉我他真的不能让我在没有固定刹车的情况下离开那里,因为他们可能会导致意外,但如果我想去另一个机械师,他可以要求拖车.
由于这款车将在午餐后很快完成,我会问他的男人是否可以吃午饭,所以我可以提早一小时把车开回去.
他告诉我他的男人早上8点进来,经常上班.他们获得了每一次休息,他的男人应该和其他人共进午餐.
这些都不是我想听到的.我想听听我会在半小时内开车离开那里,轮子和轮胎都用完了.
我的机械师直接对我说实话.你是否直截了当并诚实对待你的管理层？或者你是否避免告诉他们他们不想听到的事情？
我不会触及我不理解的一行代码,而且我不会检查我没有彻底测试的新代码行.(至少,不是故意的.)
你的问题似乎意味着某种程度上没有大量文档记录的代码使得它在没有任何单元测试的情况下通过审查.也许你参加了,也许你没有.所涉及的每个人都需要承担责任 - 包括管理层.无论如何,做了什么.你不能回去改变它.
但是,现在,在目前的时间里,每个人都有责任制止导致问题的行为.你说你花了一年的代码工作,你发现很难理解,没有单元测试.在那一年,当你努力提高理解力时,你写了多少单元测试文件并验证了解？
当你在代码中慢慢获得理解时,你添加了多少条评论,这样下次你就不必费力了？
就个人而言,我认为"Scrum积压"这个词用词不当.要做的事情列表只是一个列表 - 如果你愿意的话就是一个购物清单.当我去找机械师时,我有一份清单.我与机械师的站立会议实际上更像是一次冲刺计划会议.
冲刺计划会议是一次谈判.如果你的管理层没有那个谈判的时间,他们就没有管理任何东西.他们只是试图将10磅的狗屎塞进一个5磅的麻袋里,你有责任告诉他们.
当您参加sprint计划会议时,您需要承担一系列工作,并且您有责任为此做准备.准备意味着要了解完成列表中每个项目所需要做的事情 - 包括理解模糊代码所花费的时间以及编写单元测试所需的时间.
如果有人邀请您参加您没有时间准备的计划会议,请拒绝会议并建议何时重新安排,以便您有时间.
如果您有一个没有单元测试的现有代码体,并且某个功能可能会影响该代码的操作,则需要为可能受影响的旧代码编写单元测试.当您承诺编写该功能时,您承诺执行该工作.如果这让你没有多少时间去承诺其他功能,那就这么说吧.不要提交其他功能.
当您承诺修复缺陷时,您承诺测试您的工作.显然,这意味着为缺陷编写单元测试.但是如果它涉及没有单元测试的旧代码,它还意味着为尚未破坏的东西编写单元测试,但可能因您的更改而中断.你还要怎么测试修复？
如果您的缺陷列表仍然是一个固定的大小,那么您的团队会尽可能地修复它.礼貌地向需要理解的人解释单元测试可以防止目前使您的缺陷列表缩小的回归.
如果你没有编写那些单元测试,因为你承诺了太多的功能,那么它们的责任是什么？
当您重构代码时,您必须测试所有代码,这意味着为所有代码编写单元测试.如果你有大量的代码没有单元测试,你必须在重构之前编写所有这些单元测试.
我建议你推迟重构,直到那些单元测试到位.与此同时,如果您坚持在您估计的工作中包含单元测试,那么最终所有这些单元测试都将在那里.然后你可以重构.
一个例外是重构可测试性.您可能会发现某些代码不是为测试而设计的,并且您必须在创建单元测试之前重构依赖注入等内容.当您承诺编写需要单元测试的功能时,您承诺使代码可测试.当您承诺使用该功能时,请在估算中包含该内容.
你说你无能为力 当你承担责任并承诺做你需要做的事情时,我想你会发现你拥有所需的一切力量.
PS如果有人抱怨任何人"浪费时间"在修复单个缺陷时编写多个单元测试,请在80:20规则中向他们展示这个视频,然后将"缺陷集群"砸到他们的大脑中.