你需要从商业的角度看问题。对最终用户来说,代码是难看的还是优雅的并不重要,重要的是软件的功能。坏代码的代价是潜在的不可靠性和改变它的额外困难;它给程序员带来的情感痛苦很少被考虑。

如果你不能获得进入和重构的许可,你可以自己尝试,一次一点。每当你修复一个bug时,做一点重写以使事情更清楚。这可能会比最小可能的修复速度更快,特别是在验证代码是否正常工作时。即使不是这样,通常也可以多花一点时间修复一个bug而不惹麻烦。只是别得意忘形。

如果你每次都能让代码稍微好一点,你会感觉好多了。

站立会议

我告诉他我要把轮子对准, 我的轮胎转动了,油也换了。 我提到“哦,顺便说一下,我的 路上刹车有点软 在。他能看看吗? 我多久能把车弄回来 我得回去工作了?”

他把头伸到我车底下,砰 倒车说我的刹车漏了 油和开始失效。他需要 他的人午饭前不会吃完的,但是 我应该在下午1:30或者 能做任何其他事情 今天,我得再订一张

我问他是否能做其他事情 他真的不能让我开车离开 因为它们可能会引起事故, 但如果我想去别的地方

因为车很快就会修好 午饭后,我问他的人能不能 一顿迟到的午餐,这样我就可以拿回我的车了 一小时前。

他告诉我他的人早上8点进来

这些都不是我想听的。我想知道我会在半个小时内把车轮、轮胎和油都修好,然后开车离开那里。

我的机修工对我坦诚相待。 或者你避免告诉他们他们不想听的事情?

单元测试

然而,现在,每个人都有责任 停止这种行为 这首先导致了这个问题。你说你花了一年的时间在代码上,你觉得很难理解,而且没有单元测试。在那一年里,你努力提高自己的理解力, 您编写了多少单元测试来记录和验证这种理解?

当你在代码中挣扎,慢慢获得理解的时候,你添加了多少注释,这样下次就不用挣扎了?

就我个人而言,我认为术语“scrumbacklog”用词不当。一张要做的事情的清单就是一张清单——一张购物清单,如果你愿意的话。我去找机械师时有一张单子。我和机修工的站立会议实际上更像是一次冲刺计划会议。

sprint计划会议是一种谈判。如果你的管理是没有谈判的时间拳击,那么他们什么都没管理。他们只是想把10磅的屎塞进一个5磅重的袋子里,你有责任告诉他们。

如果您有一个没有单元测试的现有代码体,并且某个特性可能会影响该代码的操作,那么您需要为可能受影响的尽可能多的旧代码编写单元测试。当您致力于编写特性时,您就是在致力于完成这项工作。如果这让你没有太多的时间投入到其他功能上,那就这么说吧。不要使用其他功能。

当你承诺修复一个缺陷时,你承诺测试你的工作。显然,这意味着要为缺陷编写一个单元测试。但是如果它涉及到没有单元测试的旧代码,那么它也意味着为那些还没有被破坏,但可能由于您的更改而被破坏的东西编写单元测试。否则你将如何测试修复?

如果你因为提交了太多的特性而无法编写这些单元测试, 这是谁的责任?

重构

重构代码时,必须测试所有代码,这意味着要为所有代码编写单元测试。如果您有大量没有单元测试的代码,那么就必须编写所有这些单元测试 你需要重构。

一个例外是重构可测试性。您可能会发现有些代码不是为测试而设计的,在创建单元测试之前,您必须为依赖项注入之类的事情进行重构。当您承诺编写需要单元测试的特性时,您承诺使代码可测试。在您提交特性时,将其包括在您的评估中。

承诺+责任=权力

另外,如果有人抱怨有人在修复单个缺陷时“浪费时间”编写多个单元测试,请向他们展示 this video on the 80:20 rule and pound "defect clusters" into their brains.

是不是旧代码也有缺陷?如果是的话,他们从哪里来?旧代码没有“showstepper”缺陷,它通常只是越来越接近停顿。它毕竟是旧代码——它应该有相同的旧缺陷和旧限制,而不是必须立即查看的东西。Showstopper缺陷是新的代码缺陷。听起来在旧代码中有积极的开发。

如果你在那些糟糕的旧代码的基础上编写所有这些新代码,没有计划一劳永逸地修复它,对不起,当你忙于埋头工作而无法挖掘自己时,你只能做这么多。

同时,尝试学习一些设计模式。有几种方法至少可以帮助您将新代码从旧代码中屏蔽出来,但最终还是很难编写好代码来对抗坏代码。

你的冲刺听起来很混乱。难道没有一个总的方向吗?这应该决定你有多少积压工作,虽然事情每月都会发生变化,但是否有朝着某个最终目标前进的明确感觉?

新的代码腐烂了?防止这种情况发生的方法是你有一个有意义的设计,一个有意义的方向,和一个高质量的团队,致力于他们的工作质量和设计的愿景。如果你有,纪律是保持质量的关键。如果你没有那么抱歉的话,你基本上已经在毫无目的地编写代码了。它基本上烂在藤上了。

不是吹毛求疵,只是想说实话。深呼吸。慢下来。你好像需要它。看看你在这里写的。什么也说不出来。你谈论重构、scrum、showstoppers、缺陷、旧代码、新代码。这是什么意思?一切都乱七八糟的。

“新计划与传统系统”怎么样需要根据最新的理解等重构早期sprint周期代码。“showstoppers事实上是”当前企业计划的早期组件已经发布,但是遇到了问题,并且由于新的开发没有时间预算。

这些将是有意义的概念。你什么也没给我们。我知道这很激烈。我的sprint也很疯狂,我们添加了很多back;pg项,因为我们无法提前获得许多需求(我的许多新需求是由于还必须与外部监管机构竞争,正常的业务流程并不总是可用)。

但与此同时,我被必须做的事情和时间的巨大规模所打倒。所有增加到我的待办事项都需要在那里。这是疯狂的,但同时我有一个非常清楚的想法,我已经在哪里,我需要去,为什么这条路是越来越难。

退后一步,理清思路,找出相同的问题——你去过哪里,你要去哪里。因为如果你知道的话,那肯定不是很明显。如果你不能与你的同事交流任何你能理解的东西,你能和一个商业经理走多远?

旧代码总是很糟糕。有可能是一些罕见的例外写的人的名字像克尼根或汤普森,但对于典型的“代码写在办公室”的东西,随着时间的推移,它会臭烘烘。开发人员变得更有经验。新的实践,如持续集成,改变了游戏。什么都忘了。新的维护人员不能理解设计,希望重新编写。所以你最好接受这一切。

一些随机的事情可能会有帮助。。。

• 和你的团队谈谈。分享你的经验和你的担忧,同时避免“你的旧代码很烂的人”(因为明显的原因),看看共识是什么。你可能并不孤单。
• 忘了你的经理吧。不要将它们暴露在这种细节级别上—它们不需要考虑新代码和旧代码的区别,如果考虑了,它们可能不会理解。这是您的团队需要解决的问题,如有必要,请告知您的PO
• 敞开心扉,你可能会把东西扔出去。其中一些旧代码可能与用户不再使用或无法采用的特性有关。为了让这项工作为您服务,您真的需要更上一层楼,考虑代码在哪里真正提供了用户或业务价值,而在哪里它只是一团泥,没有人有足够的勇气做出决定。谁敢,谁就赢。

总的来说,在这种情况下获胜不是靠编码技巧,而是靠明智的选择和处理人的方面。

希望有帮助。

我建议跟踪有多少bug和代码更改涉及到您的“旧代码”,并在下一次团队会议上向您的经理或其他开发人员演示。有了这一点,它应该足够简单,让他们相信需要做更多的工作来重构你的“旧代码”,并使之与你的“新代码”并驾齐驱。

记录“旧代码”中最难理解的部分也是谨慎的。这些也是“旧代码”的一部分,一旦获得批准,就应该首先重构它们。

尝试一下:把你的班级分成最差的10%,最好的10%和其他的。把清单交给你的管理层,说,“我预测下个季度的大部分漏洞都会在第一组中发现。”, cyclomatic complexity ,测试覆盖率-任何工具对您来说都是方便和舒适的。然后坐下来看着——做正确的事。现在,当你说“我想投入一些资源来改进我们的坏代码,减少bug和维护成本——我知道在哪里投入这些精力,看到了吗?”

您可以创建新代码如何工作以及类和函数如何相互关联的图表和草图。你可以用FreeMind或者Dia。我绝对同意记录和评论你的代码。

• 无评论或文档
• 较少面向对象
• 错误的变量/函数名
• ...

我不知道这是否是一个真正的答案,但它肯定是为我工作。对于旧代码,您可能需要重新阅读整个代码,并在记住功能时添加注释。

希望有帮助。

与产品负责人交谈 ! 解释一下,在重构旧代码上投入的时间将给他带来好处,一旦这个障碍被消除,团队在新特性上的速度就会更快。

除了以上提到的好方法外,您还可以尝试以下方法:

• 尝试成对编程,至少对有意义的部分是这样。这是一个有效的方法,让审查,重构代码的做法。
• 试着让重构进入“完成”的定义。然后它将成为估算过程的一部分,并相应地分配。因此,done的定义可能包括:编码的、单元测试的、功能测试的、性能测试的、代码评审的、重构的和集成的(或者类似的东西)。

清除旧代码:

• 单元测试非常有助于您重构和了解事物的工作方式。
• 我同意这样的评论:大规模重构需要一个商业案例。但是,小规模的重构可以很容易地包含在评估中,并将提供即时的回报。i、 e:我花了2个小时重写一篇文章,但无论如何,我都会花这段时间寻找bug。

您可能还需要考虑让产品所有者和scrummaster为旧代码和新代码捕获一个单独的速度,并相应地使用它。

如果有一个需要的新特性,并且您可以描述一个非压倒性的代码块,那么您就可以得到管理层的许可,用具有所需新特性的新代码替换旧代码。当我这么做的时候,我不得不写一个有点难看的填充层来满足我不打算接触的软件部分的旧接口。还有一个测试工具,它可以使用现有的代码和新的代码来确保新的代码,就像通过填充层看到的那样,可以欺骗应用程序的其他部分,使其认为没有任何变化。通过重新设计我们重新设计的部分,我们能够显示出巨大的性能优势,与所需的新硬件兼容,减少了我们每个现场站点对管理应用程序空间的专业技能的需求——以及新代码 是 更易于维护。最后一点对用户来说无关紧要,但返工带来的其他好处足以吸引用户,因为它的优点是数据库转换有些痛苦。

另一个较为平庸的成功案例是:我们有一个相当不错的故障跟踪系统,已经有多年的历史了。我们的应用程序有一个子系统,它以烧掉维护程序员的速度而闻名。很明显(嗯,在我看来)它需要一次大的重写,但管理层对此并不热心。我们能够在故障跟踪数据中挖掘历史记录,以显示维护该模块所需的人员配置水平,尽管如此,每月针对该模块的故障通知单仍然以恒定的速度到达。当面对这样的实际数据时,即使是那些长期以来对该子系统的人员配置和再工作吝啬的管理人员,也能看到指派人员来重做该模块的好处。

一个失败的例子:还有一个令人难以置信的丑陋模块,一直是一个痛处。唉,我还不够聪明,无法理解这个由人渣和恶棍组成的特别可怜的蜂巢的实际接口,至少在名义发布时间表的时间框架内是这样。我想相信,如果有更多的时间,我们也可以找到一个合适的计划来重新工作系统的一部分,也许一旦我们理解了它,我们甚至可以确定用户想要的改进,我们可以适应重新编写。但我不能保证你能在每个盒子里找到奖品。如果这个框对你来说是完全模糊的,那么切掉它的一大块并用干净的代码替换它是很难做到的。负责该模块的人可能是最有能力制定攻击计划的人,但他将频繁发生的撞车事故和外地求援电话视为“工作保障”。我认为管理层从来没有真正意识到,对于一个渴望变革的人来说,他需要被放在一边,但这可能是需要的。

德鲁