(译)重写代码会失败的几个征兆

Author Avatar
XibHe 8月 10, 2018
  • 在其它设备中阅读本文章

总有一个理由去重构项目。也许你是一个的取得了一些成功,而你的工程师们吵着平台需要改进,要从头开始进行项目重构的CEO。也许你是主管或IT领导,在反复权衡重写老旧项目需要付出多大的成本。也许你是一个已经开始重写老项目的主程(我是疯了吗?)。无论如何,你可能已经知道重构老项目,像关于税收改革或无政府状态的讨论一样,只是稍微有点危险,你永远不知道自己在重构时实际遇到的难题和之前想象中会遇到的根本不是那么回事。

但是,尽管一些德高望重的人(当然,其实只是 Joel Spolsky ),对项目进行重构,即使在某些时候,这是正确的选择。但重建仍是一场危险的旅程,你的重构工作很可能由于一些无法预知的难题而失败。

因此,我们提出 “为达到目的,该如何去做”,以下五个标志决定了重构最终的成功与否,你究竟是不是疯了,要看你最终重构的结果如何。

1. 没有清晰的重构目标,为重构而重构。

重构必须增加新的价值。事实上,如果在重构的前6个月仍看不到项目重构所带来的价值,你就应该思考项目重构的意义是什么?需要慎之又慎,因为进行大规模的重构工作会耗费大量的资源,老项目30个人花费一年多的时间写的,而现在却只花费6个月的时间进行重构。除非你的部门是 Google X 能够负担起长时间开发的费用。你最好能考虑一下。

如果你是一名经理,你自己不知道项目重构能带来的价值是什么,也许是时候结束重构了,或者如果你已经确定你想得到什么,做设计的冲刺与实际用户清楚地捕捉这一愿景和然后重新评估,如果重建的轨道上与您的用户想要什么。 进行 design sprint 与实际应用场景结合重新进行项目评估。

2. 你将面对大范围的转换式重写

项目功能的转变很容易。只需要切换DNS记录和BOOM就能看到,应用程序在每个方面的全面变化是美学上令人愉快的。项目整体功能转换的重构是所有重构中最需要警惕的。它仅适用于非常简单的系统。有它仅适用于非常简单的系统前期准备工作要做,这就是为什么渐进式的重构方式更好,因为:一个大的功能性重构等效于瀑布式方法

如果你是一名经理,你需要让你的开发人员认识这一点,因为他们很可能正在努力推动一个大的功能性重构。当然,他们从来没有使用这些词,而是选择像“干净的石板”或“重新构架”的词语,但询问他们,我们还要多久可以将这些代码部署到生产环境?如果答案是3个多月了……那么他们很可能在做一个大范围的功能性重构。

3. 重构后的新系统速度比老系统慢

这很简单:如果你在进行重构的同时,也在改进现有的老项目,以对冲重构风险并保持竞争优势(这是一个好主意),但重建您现有的传统产品是不是能以更快的速度添加相同的特性,重构将永远也无法完成。

您的重建团队需要由技术优秀的开发人员组成,他们了解最新的技术,并有足够的脑力去理解遗留系统的复杂性(有趣的是,这似乎是由 **Kernighan 定路和 Peter Principle 混合而成的)。

此外,请确保你的重构小组(一个或多个)能够持续进步更快!不要基于第2-3个月的重建速度来判断。一个项目在初期总是进行的很快,因为复杂的问题尚未考虑,但在进行一段时间后速度就会减缓:

4. 你是不是和那些旧系统中的专家合作。

任何专家都可以提供帮助 —— 旧系统的前开发人员,财务部的Marge,甚至是高级用户。这些人对重建至关重要,因为他们一开始就知道应用程序的所有问题。没有这些人,你会成为特斯勒定律的受害者。最终生成新系统的价值低于老版本。

可以将它们看作人类测试套件。他们会在几分钟内发现在重新构建中可能永远不会发现的细微实现错误。

涉及到的人。让他们觉得他们对重建是有帮助的(因为他们是参与者)。尽早得到他们的反馈。

5. 你打算删除那些很难用的功能

假设您正在重建一个系统,该系统已经取得了一些成功,并且正在积极地为用户提供价值。在“精简化”构建的名义下,很容易陷入使用更少特性进行重构的陷阱。但是,这是否有意义?是的,传统的应用程序可能是缓慢的和丑陋的。但仔细想想,你的用户愿意忍受缓慢的和丑陋的使用这个系统!如果删除,他们使用的功能,你的用户会恨你。

这是否意味着你应该盲目地复制遗留系统的特性?当然不是!遗留技术所必需的一些特性已经变得僵化。现在有一些类似OCR的东西,可以取代表单字段的页面。这意味着你可以自由地重新想象这些特性或创建一个新的流程,该流程允许你删除操作,但是你不能删除需要完成的任务/整个流程,无论多么诱人。

让我们做个总结

我希望你能注意到,在重构过程中,我们关注的是真实的、当前的价值交付。这就是为什么每次重新构建都要从彻底的设计冲刺开始,挖掘所有的增值特性。这次sprint 的核心方法是通过访谈获得最终用户和涉众的反馈,并通过原型确认你的发现。这确保了产品仍然以你所期望的方式满足市场需求,并在基于真实用户反馈的重构过程中留下了创新的空间。

如果你觉得必须在通过重新构建复制一个特别繁重的旧特性和添加新特性之间进行选择,那么你有一些选择。一种选择是使用 Martin Fowler’s strangler pattern 模式,通过这种模式,你可以在重新构建中创建新的功能,这些新功能可以同时且相对无缝地与旧功能集成,从而保留了那些功能,而无需重新创建它们。

有什么问题或意见吗?有什么问题吗?请随时联系我们!

原文地址

5 Red Flags Signaling Your Rebuild Will Fail

附录

Google X

Google X,是谷歌公司最神秘的一个部门,位于美国旧金山的一处秘密地点,该实验室的机密程度堪比CIA,仅少数几位谷歌高层掌握情况,在其中工作的人,都是谷歌从其他高科技公司、各大高校和科研院所挖过来的顶级专家。Google的X实验室在联合创始人布林的带领下开发过谷歌眼镜和无人驾驶汽车等项目。

Design Sprint

设计冲刺(Design Sprint)是近些年从敏捷开发(Agile)延展出来的一种产品创新方法。由于谷歌创业部门(Google Venture)和用户体验设计部门(Google UX)、研发部门的充分运用和大力推广,因此在业界它也常常被称为Google Design Sprint。 与更早一些诞生的设计思维(Design Thinking)对照,我们注意到二者都是面向产品和服务的快速创新、解决棘手问题的体系,它们拥有高度相似的运作流程,分享完全一致的、以用户为中心的创意理念。

–EOF–

若无特别说明,本站文章均为原创,转载请保留链接,谢谢