什么时候可以牺牲设计的“整洁度”来完成项目?


15

在需要尽快完成工作并做好工作的产品上工作时,何时才能牺牲设计的可维护性和“整洁”才能使事情快速完成并交付使用?而且在什么程度上还可以,特别是当使它变得“整洁”的技术对我来说是新的时?


3
仅在绝对必要时。
FrustratedWithFormsDesigner

1
这是我工作的常态。“现在就可以付钱,或者以后可以付钱给我”从未如此真实。
MetalMikester 2011年

听起来像是迫在眉睫的最后期限...

1
我会采取逆势观点,并且总是说。如果一个项目没有完成,没人会在乎它是否整洁。
drxzcl 2011年

1
@MrJ,我实际上是在考虑用户。
drxzcl 2011年

Answers:


18

请记住,您受雇是为了支持业务。在某种程度上,您的软件正在影响业务的底线。您需要在技术上完美的解决方案,产品的上市时间以及业务将从中获得多少收益之间取得平衡。

以我的经验,开发人员经常会担心技术的完善。但是有非常合理的理由要牺牲质量属性,例如可维护性或性能,以便更快地将产品推向市场。这取决于业务和产品。但是“总是追求完美的设计”是一种过于简单的方法。

归根结底,唯一重要的是业务价值。弄清楚如何在短期和长期内最大化它,并针对该目标。


3
我同意您的回答的精神,但您缺少一些细节。You need to strike a balance between a technically perfect solution, and the time to market of your product我不同意,这超出了开发人员的责任。他们绝对必须保持对此的意识,但应将信息提供给负责做出业务决策的人员。
StuperUser 2011年

2
以暴雪为例。他们在游戏中取得了巨大的成功,他们并不真正在乎上市时间,因为他们认为出众的质量最终会得到回报。确实如此,尽管可能不适用于所有类型的软件。
猎鹰

1
我绝对同意@StuperUser和@Peter Rowell。通常,开发人员有责任将技术风险,偷工减料等问题传达给做出决定的食品链上层人士。如果那是您的角色,那么您应该专注于尽可能准确地进行交流。但是,您越了解推动业务价值链的因素,您就越能获得良好的沟通。
RationalGeek

1
@Falcon Blizzard确实可以在长期,稳定,令人愉悦的游戏中牺牲长期游戏的早期收益。这也许对他们来说是适当的平衡。但这并不是在所有情况下都适当的平衡。
RationalGeek

4
现实情况是,大多数新软件产品将在市场上失败,这不是由于质量问题,而是因为客户根本不希望它们。因此,花大量时间/精力在产品的版本1中创建可靠的可管理体系结构可能不是最佳的资源利用方式。努力把东西送出去的商人不是你们中许多人认为的白痴;将产品交到客户手中以确定其可行性是一件非常明智的事情。
克里斯托弗·约翰逊

12

“技术债务”一词非常方便帮助您做出这样的业务决策。您现在不做的任何工作都会在以后引起一些工作。就像财务一样,承担债务也是有风险的,但是如果您以后能够偿还债务,则值得利用。

话虽如此,技术债务在投资回收期并不是1:1的比率。错误在发布后修复起来的代价更高,并且从凌乱的旧版系统进行开发时,对未来生产力的影响可能令人震惊。您可能会花在解决错误上的时间增加一倍,或者花费的工时和资源可能是它的1,000倍。

您在此决策中的工作是了解您正在考虑的特定切角部分的后果,然后将这些后果传达给制定业务决策的人员。这种特殊的估计技能可能需要您进行大量研究和工作才能发展良好,但是在您的职业生涯中这将是非常宝贵的。


1
+1。技术债务确实是描述这一点的最清晰方法。
crazy2be 2011年

8

接受后,后果由所有者/客户/用户理解。

水管工必须拿出垃圾进行维修。我想在此期间使用水槽,但是他将不得不花费时间和材料向我收费,以便使用可能会破裂的胶带将它们放入临时管道。这也将延迟将处置送回修理厂。如果我在接受附加帐单的前提下理解会冒木log的风险。可以接受修复,这将需要更长的时间来修复,并且需要更长的延迟才能将其放回原处。

您现在可以按时按预算进行,但从长远来看,牺牲/承担更高的费用。非技术人员很难理解这一点,但这就是销售人员的目的。


5

很多人在学习新事物时会放弃快速进入的道路,而只是按照自己一贯的方式去做。如果这是一种模式,那么不仅会使您的代码受苦,而且您作为程序员的技能也会受到限制。

尽管如此,最终只有唯一成功的软件是已发布的软件。


“不过,最终,唯一成功的软件就是发布的软件。” 直到它崩溃并烧毁了几年,因为它的架构不正确。近视行动。
韦恩·莫利纳

1
如果您从不发货,那么几年后您将永远无法做到……
杰里米(Jeremy)

如果由于眼光短浅的管理而无法运送不会长期困扰您的东西,那么您就不应该首先从事商业活动!
韦恩·莫利纳

3

在软截止期限过去之后。即使这样,“ OK”的程度也很低。经过艰苦的最后期限,这当然是没有意义的。因为那是硬期限的本质。

此外,这招致技术债务。您每天花一小时的时间来完成git-er-done的工作,当您下次触摸此项目时,它将花费大约两倍的时间。如果需要,那么最好赶紧运送,然后立即开始固定所有鸭子胶带。几年后重返黑客眼的项目是一场噩梦。如果您永远不会再触摸它,那就这样吧,没人会在乎的。但是,我离开项目的唯一谎言就是永远换工作。

但是请记住,安排这些时间是项目经理的工作。如果您赶时间,那是PM的错。正确地做一次,然后从容正确地做。生命太短暂了。


2

这里发布的所有其他答案都很好。我想补充一点,作为项目的开发人员,您是设计的管家(保护者)。

如果您不支持适当的技术解决方案,那么我没有其他人向您保证。您应该始终坚持以正确的方式对待老板,而项目经理应该始终坚持最后期限。

希望如果您在一个合理的组织中,将会达成一个折衷方案,以帮助您按时完成任务,同时又不要偏离设计太远。

话虽这么说,但不要以为如果没有达到PM的最后期限,世界将会终结并且该项目将失败。通常情况并非如此,在大多数情况下,PM的截止日期很短且有调整的余地。

我几乎在PM计划中遇到的每个最后期限都是人为的。他们会保护自己的牙齿和指甲,然后假装否则,因为如果PM赶紧最后期限,那么PM看起来很糟糕!

仅仅因为PM看起来不好,并不意味着项目失败了。如果您了解这一点,您会惊讶于您可以使PM弯曲多少。


1

报价给客户整齐的设计。如果他们不接受该报价,则请详细分析每个组件的成本(通常成本==开发时间)。如果他们选择的话,让他们从“点菜”中删除商品。许多人会为节省诸如测试和设计之类的“无用”东西而节省时间。解释这种方法的风险,但是如果他们接受该风险,则请按照指示进行。如果我只有足够的钱来买旧车,那我就去买旧车,即使我知道它可能会在8个月内坏掉。您的客户有责任权衡这些风险并接受后果。

您不想做的一件事就是告诉客户,他们只花了(并收到)未经测试的垃圾软件,便认为自己拥有设计精美的软件。如果出了点问题(很可能会发生),在第一种情况下,它们看起来很糟糕,但是在第二种情况下,您看起来很糟糕。


1

这是从来没有好,但有时你必须妥协的完成一个项目的缘故。可悲的现实是,大多数商人完全无知,并且愿意为以后的事情牺牲可维护性。诀窍是知道如何达到平衡。也许该项目不会像可能的那样整洁,但只要不是猪圈,那是值得的妥协。


0

这完全取决于以下问题:“您或其他任何人都可以在以后修改它吗?” 如果是的话,您应该尝试采用“整洁”的设计,否则您将不得不将所有内容扔掉并在6个月后重新开始。

当然,您可以使整洁度过高,但是一般来说,整洁些可以节省您以后的工作。


4
无论客户告诉您什么,都没有不需要维护的产品。
Edward Strange

@ crazy-eddie几乎没有。这是一个充满挑战的问题。我真的无法想到在许多情况下您会对这个问题回答“否”。甚至可以想象,即使是一个只适用于一件事情且永远不会再次使用的快速脚本,也可以稍后对其进行编辑和翻新。
Jo-Herman Haugholt 2011年
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.