安排定期清理代码是个好主意吗?[关闭]


42

我正在管理一个小的开发人员团队。我们经常决定要花一两天的时间来清理代码。

安排定期的时间(例如每2个月1周)来清理我们的代码库是个好主意吗?


9
我希望首先开始在问题跟踪工具中注册所有需要清除的内容。分析跟踪器中记录的问题可能会给一个更好的(更好的)想法,这将是最适合特定项目的方法
gnat

4
最好安排一个定期的时间进行代码审查
l46kok 2013年

1
您说“收拾”是什么意思?它是美化代码还是处理所有的FIXME和TODO标签,还是从快速编写的代码中提高性能?或者是其他东西?这些中的任何一个都可以归类为清理,但是我将对它们分别赋予不同的优先级。
保罗

另一个“封闭得太受欢迎了”,是吗?
MGOwen

Answers:


100

没有。

在处理它时对其进行修复:

  • 如果您等待重构工作量,就会忘记很多事情,而不得不花时间再次熟悉它。
  • 您将不会得到“镀金”代码,该代码由于需求发生变化而永远不会被使用

2
我在这个答案上的钱..
SonerGönül2013年

2
+1为出色的答案。您将不会因为需求发生变化而最终无法使用的“镀金”代码
Md Mahbubur Ra​​hman

8
在一个完美的项目,完善的管理和一支团结一致的优秀开发人员的团队中,这个答案是正确的。不幸的是,我从事该行业的十年来从未见过或听说过这样的项目。
2013年

3
尝试执行此操作,但是在无法执行此操作时(由于时间压力或因为您根本不知道如何正确执行操作而将其发生),请在票务系统中创建票证。这样,您就可以在问题仍在脑海中重现,而不仅仅是在问题最终开始引起问题时再来解决问题。
萨里安

1
我认为这是一个很好的建议,但不能解决所提出的问题。Haivng管理着一个有着可怕代码库的团队(在我到达那里之前是可怕的)。这是花费大量时间解决重构和清理特定功能的时间。我们称它们为基础设施项目,并将它们纳入我们可能的每个冲刺中。这些东西通常不是其他变更的一部分,而是团队已确定为问题区域的东西。我们进行了季度回顾,并将定期更新此列表。
Bill Leeper 2013年

21

我个人的观点:90%的项目都是绝对需要的。

特别是对于那些受销售驱动的项目,通常会大力推动每个版本中都包含新功能,并且您不可避免地最终不得不妥协更好的直觉,并在此四处引入一些弊端。

最终,通过这些小小的折衷,您已经累积了足够的“技术债务”,您最终不得不花大量时间来解决代码库中的缺陷,而无法充分利用它的全部潜力。

通常,以这种方式生成两种类型的问题:

  • 小型变量很容易修复,但可能是系统性的,例如参数命名不正确,错误处理不完整等。它们通常不会对它们所在的代码块产生什么影响。处理这些问题的最佳方法是代码审查,并在编写/修改代码时对其进行检查。正如其他人所指出的那样,无需预留一个特殊的重构周期来修复这些错误。
  • 较大的问题可能是由于规格不完整或早期的设计决策不当,或者两个开发人员/团队针对同一问题创建了两种不同的解决方案。这些通常很难修复,需要齐心协力进行修复。结果,它们通常被推迟,直到成为永久的麻烦为止。这类问题需要花费一定的时间来解决。

我通常会尝试每3到4个周期为纯重构/错误修复周期保留时间。我总是要求开发人员在对代码库感到沮丧时告诉我。并非每个开发人员都需要进行清理工作-您通常(但并非总是)使团队有些混乱,因此在任何给定时间只有一个团队在进行清理。


1
我不认为增加大推力的数量是一个敏捷问题。
JeffO

2
@JeffO不,这不是一个敏捷问题。这是一个管理问题。从我所看到的来看,受销售影响很大的公司倾向于采用积极的发布周期和大型功能集。敏捷策略往往会吸引这些公司(无论他们是否真正遵循这些策略)。虽然我喜欢敏捷开发,但我的经验表明,当一家公司称自己为“敏捷”时,通常意味着我可以期望在代码库中看到大量的技术债务。
pswg

我想如果他们根本没有方法论,他们可以随便叫什么。由于敏捷是当前的流行语,因此它是最有吸引力的。自从我从事瀑布项目以来已经有一段时间了。这在其他许多方面都是一场灾难,以至于我从不将它当作反对该方法论的论据。
JeffO

在任何项目中,无论是否敏捷,重构和清理代码都是随手可做的,以使技术负担不断降至最低。如果您在估算中没有考虑到这一点,则必须开始这样做。在您需要停止一切修复工作之前,您不能让技术债务累积。而是遵循侦查规则:“始终让代码保持清洁的状态。”
ChristofferHammarström'13

以我的经验,没有Scrum经验的团队如果没有遵守良好的编码原则(如XP),有时会过多地专注于功能(故事)。相反,他们应该说直到代码足够“好”才完成一个故事,但是并不是每个人都有足够的骨干力量在迫在眉睫的期限内做到这一点。有了敏捷,您往往会在更短的时间内有更多的截止日期,因此我也将其与敏捷方法相关联,而我完全意识到它们不是原因。
markijbema

11

在签入(Subversion)或与主开发分支(Git)合并之前,我让我的开发人员整理代码。

我让他们执行以下操作:

  • 删除不相关的评论
  • 确保适当地命名其方法,参数和变量
  • 确保它们的类有结构,并且将项目封装为应有的样子
  • 重构以提高可读性并减少任何代码异味

对于较大的项目,在从开发分支合并到主分支之前,将对代码进行正式审查。

我认为“投入时间”将意味着它可能会被推迟或由于涉及的工作量而推迟。通过让开发人员在每个签入中进行操作(相当于JIRA中的变更请求/问题),则可管理性大大提高。


出于好奇:您为什么要使用两个不同的VCS?
Eekhoorn

2
有/有一个迁徙阶段。现在,我们已经迁移了大多数SVN存储库,我在某些情况下都提到了这两个存储库。
2013年

这就是我的工作。如果要返回代码以改善功能,请在签入之前清理代码并进行重构。
Barfieldmv

1
这不会解决那些可能不在产品团队的功能请求中的问题。
Bill Leeper 2013年

9

我认为不是。如果您在遇到技术债务与解决技术债务之间花费了太多时间,那么您将失去问题根源。需要花费更长的时间来修复,而且往往更糟。最重要的是,人们离开了破碎的窗户,因为它不是“清理一周”。

就个人而言,如果我知道我们之前在冲刺中创建了一些冲刺,那么我会为每个冲刺进行技术债务清理谈判。它使债务保持在人们的脑海中。它限制了使用问题代码的代码数量,因此重构更加容易。它可以防止技术债务堆积。而且它可以帮助开发人员避免将某物拍打在一起,因为我只是要让他们在下一个冲刺时做(所以最好一开始就做)。


您的第二句话与第一句话矛盾。您说不,但是然后说您将这些事情纳入每个冲刺中。以某种方式安排时间来完成它。
Bill Leeper 2013年

2
@BillLeeper-恩。当我听到“正常时间”时,这意味着有一定的间隔进行清理工作。IMO,那是不对的-一直都是进行清理工作的正确时间。
Telastyn

1
好点,我确实同意常规时间不能很好地工作。往往优先考虑导致其被取消等
比尔利珀

4

我肯定会说,但附带条件:应该经常进行,最好每周进行一次。我相信,定期进行定期代码审查,再加上实际对代码审查产生的项目采取行动,将会很快获得回报。查看pswg的答案

每2个月1周绝对不够频繁。这可以与其他大多数回答“否”的人说。这些答案中的大多数的要点是,如果等待时间太长,您将不再与代码保持联系,并且通常需要更长的时间来修复/清理/重构。


为此,我们进行了“技术债务周二”。它的中途丢了一个以色列工作周,让我们退后一步来处理问题
Zachary K

1

尚不清楚您是否需要偶尔进行一次额外的代码清理练习。从这个意义上讲,是的。无论我们遵循什么实践,总会发生一些退化。

首先,您不应以此为借口不做正确的事情[应用SOLID原则,相关的单元测试,检查等]。


1

我认为当前两个流行的“否”,“是”答案是同一真相的两个方面。记住,OP是在谈论他所管理的团队,而不仅仅是他个人。我们不能认为该小组中的所有开发人员都具有足够的纪律性,可以编写干净,易于阅读的代码。还有外部压力和敏捷风格方法论的问题。同样,即使人们尽了最大的努力,他们在风格上的差异也意味着他们可能会编写分开时被认为是干净的代码,而与其他人一起考虑时则是不干净的代码(更不用说笨拙的界面了)。

另一方面,在我看来,“在解决它的同时修复它”是一个理想的追求。您可以通过以下方式使代码更加“固定”:

  • 仔细的对等CR
  • 编写单元测试以及代码本身
  • 采用编码准则
  • 使用自动格式化程序和lint(但使用YMMV)
  • 等等

现在,如果OP的团队采用了上述方法,并且如果他鼓励下属(例如在代码审查期间和定期的代码清理会话期间)尝试预见陷阱并提前避免丑陋,那么随着时间的推移,他/他们将希望减少清理时间。(然后,他们可以将这段时间投入到文档,更深入的重构以及他们所编写和合并的内容的知识共享中。)


1

我认为安排常规时间非常好,无论是常规瀑布式项目中的任务,还是敏捷项目中的故事。设定时间可能不如将其用于计划中那样有价值。这使您可以将其作为计划的一部分完成,而不必取消清理日,因为您在项目上落后了。

在管理了一个拥有大量代码债务的项目之后,定期进行这些工作对于使工作顺利进行至关重要。我们有些东西很大,有些东西很小。

经过几个月的工作,我们的运营团队领导告诉了我一切运行得如何顺利。

每个项目看起来似乎并不多,但就像所有债务一样,它会广告化。


1

理想的答案是“否”,因为您采取了必要的步骤来避免使它成为必需(由于前面已经提到的几个原因,请进行清理)。

这最终可能是目标,但您可能拥有一支远未付诸实践的团队。

经理必须承担一些责任这并不总是开发人员的错。经理可以说一件事,但是他们开始推动项目完成并提出促进不良做法的建议。他们可能从字面上说:“我们稍后再清理”,或者如果可行,那就足够了。

您可能必须先指定一个特定的时间来证明这一点很重要。一旦知道您的团队有能力清理他们的代码(不是给定的),就可以尝试更频繁地合并它。

最终,您不必设置时间。

就个人而言,我努力解决一个新问题并使它工作,同时努力使事情保持整洁。我在这方面做得更好,但经常会故意休息一下并清理一下。对我来说这是一种不同的心态。最终,扎实的习惯成为习惯。


-1

不,您应该在编码时执行此操作。如果使用的是TDD,这称为重构。当您等待一两个月来修复和清理代码时,问题在于您可能会更改代码的行为,因为您不会记住每段代码。

我建议进行重构,该重构基于首先对必要的代码进行编码以使某项工作正常进行,并在工作完成后立即对其进行重新设计,优化并使其美观。


无论是否使用TDD,这都称为重构。这个问题与TDD无关...
Ben Lee
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.