在需要尽快完成工作并做好工作的产品上工作时,何时才能牺牲设计的可维护性和“整洁”才能使事情快速完成并交付使用?而且在什么程度上还可以,特别是当使它变得“整洁”的技术对我来说是新的时?
在需要尽快完成工作并做好工作的产品上工作时,何时才能牺牲设计的可维护性和“整洁”才能使事情快速完成并交付使用?而且在什么程度上还可以,特别是当使它变得“整洁”的技术对我来说是新的时?
Answers:
请记住,您受雇是为了支持业务。在某种程度上,您的软件正在影响业务的底线。您需要在技术上完美的解决方案,产品的上市时间以及业务将从中获得多少收益之间取得平衡。
以我的经验,开发人员经常会担心技术的完善。但是有非常合理的理由要牺牲质量属性,例如可维护性或性能,以便更快地将产品推向市场。这取决于业务和产品。但是“总是追求完美的设计”是一种过于简单的方法。
归根结底,唯一重要的是业务价值。弄清楚如何在短期和长期内最大化它,并针对该目标。
You need to strike a balance between a technically perfect solution, and the time to market of your product
我不同意,这超出了开发人员的责任。他们绝对必须保持对此的意识,但应将信息提供给负责做出业务决策的人员。
“技术债务”一词非常方便帮助您做出这样的业务决策。您现在不做的任何工作都会在以后引起一些工作。就像财务一样,承担债务也是有风险的,但是如果您以后能够偿还债务,则值得利用。
话虽如此,技术债务在投资回收期并不是1:1的比率。错误在发布后修复起来的代价更高,并且从凌乱的旧版系统进行开发时,对未来生产力的影响可能令人震惊。您可能会花在解决错误上的时间增加一倍,或者花费的工时和资源可能是它的1,000倍。
您在此决策中的工作是了解您正在考虑的特定切角部分的后果,然后将这些后果传达给制定业务决策的人员。这种特殊的估计技能可能需要您进行大量研究和工作才能发展良好,但是在您的职业生涯中这将是非常宝贵的。
很多人在学习新事物时会放弃快速进入的道路,而只是按照自己一贯的方式去做。如果这是一种模式,那么不仅会使您的代码受苦,而且您作为程序员的技能也会受到限制。
尽管如此,最终只有唯一成功的软件是已发布的软件。
这里发布的所有其他答案都很好。我想补充一点,作为项目的开发人员,您是设计的管家(保护者)。
如果您不支持适当的技术解决方案,那么我没有其他人向您保证。您应该始终坚持以正确的方式对待老板,而项目经理应该始终坚持最后期限。
希望如果您在一个合理的组织中,将会达成一个折衷方案,以帮助您按时完成任务,同时又不要偏离设计太远。
话虽这么说,但不要以为如果没有达到PM的最后期限,世界将会终结并且该项目将失败。通常情况并非如此,在大多数情况下,PM的截止日期很短且有调整的余地。
我几乎在PM计划中遇到的每个最后期限都是人为的。他们会保护自己的牙齿和指甲,然后假装否则,因为如果PM赶紧最后期限,那么PM看起来很糟糕!
仅仅因为PM看起来不好,并不意味着项目失败了。如果您了解这一点,您会惊讶于您可以使PM弯曲多少。
报价给客户整齐的设计。如果他们不接受该报价,则请详细分析每个组件的成本(通常成本==开发时间)。如果他们选择的话,让他们从“点菜”中删除商品。许多人会为节省诸如测试和设计之类的“无用”东西而节省时间。解释这种方法的风险,但是如果他们接受该风险,则请按照指示进行。如果我只有足够的钱来买旧车,那我就去买旧车,即使我知道它可能会在8个月内坏掉。您的客户有责任权衡这些风险并接受后果。
您不想做的一件事就是告诉客户,他们只花了(并收到)未经测试的垃圾软件,便认为自己拥有设计精美的软件。如果出了点问题(很可能会发生),在第一种情况下,它们看起来很糟糕,但是在第二种情况下,您看起来很糟糕。
这是从来没有好,但有时你必须妥协的完成一个项目的缘故。可悲的现实是,大多数商人完全无知,并且愿意为以后的事情牺牲可维护性。诀窍是知道如何达到平衡。也许该项目不会像可能的那样整洁,但只要不是猪圈,那是值得的妥协。
这完全取决于以下问题:“您或其他任何人都可以在以后修改它吗?” 如果是的话,您应该尝试采用“整洁”的设计,否则您将不得不将所有内容扔掉并在6个月后重新开始。
当然,您可以使整洁度过高,但是一般来说,整洁些可以节省您以后的工作。