代码之家  ›  专栏  ›  技术社区  ›  dsimcha

如何处理代表设计缺陷的小错误?

  •  3
  • dsimcha  · 技术社区  · 7 年前

    我正在一个项目中工作,在这个项目中,我有一些相关的bug,这些bug在功能丧失方面相当小。它们基本上是很小但很烦人的美学问题,基于功能的丧失,应该最终得到解决,但不是作为首要任务。然而,这些错误是由一个基本的、成熟的设计缺陷引起的,要纠正这个缺陷将是噩梦。

    当面对功能上很小但由于设计缺陷而导致的错误时,通常最好将它们视为ShowStopper,以避免将自己进一步绘制到某个角落,或将它们视为低优先级的错误,继续使用功能上更重要的东西,并希望稍后您能找到解决方法,当项目是否更成熟并优先修复小错误?

    3 回复  |  直到 7 年前
        1
  •  1
  •   Luis Miguel Serrano    16 年前

    如果功能损失方面的问题很小,并且功能损失在正在开发的软件解决方案的上下文中不相关,我建议您尝试检查它对其他未来功能的限制程度,如果它在视线内没有影响,请继续。

    我这么说是因为通常,当你完成一个软件项目时,无论你构思的多么小和多么好,你最终都会有一个成熟度,它会让你意识到你在设计中可能做出的缺陷和改变。基本上,如果最后你不得不重新开始,你总是会以不同的方式开始。

        2
  •  1
  •   Gian    16 年前

    我会继续,好像它不是一个展示阻止,但开始在精神上准备的事实,你可能不得不做一个主要的重写最终。如果你最终不需要这样做,那是一个额外的奖励。尤其是如果你在一个团队或管理的环境中工作,确保它在将来可能影响的任何开发中被明确地标记为风险。

        3
  •  1
  •   MCain    16 年前

    管理层总是希望在你的时间里看到他们的投资回报。因此,管理层希望看到一个及时的发布,他们也希望看到您在Y小时内修复了x个错误。但是,这并不意味着你需要忽略设计。当你修复缺陷时,准备重新设计你看到缺陷的部分。发布之后,准备好展示您的理由,说明为什么需要重新设计它,以及修复它需要多长时间。写下来,当它是新鲜的,当你正在修复这些虫子。

    在理想的世界中,我们将有无限的时间根据需求的变化不断地重新设计。在现实世界中,我们必须权衡改变设计的成本与继续进行当前设计的成本。首先,您可以量化在当前设计中修复bug所花费的时间,并将其与重新设计此组件所需的估计时间进行比较。