维护软件提示–我们可以做什么

如果您问大多数开发人员，他们会告诉您维护工作很糟糕 。 理解和修复别人的糟糕代码很难。 这很乏味。 这令人沮丧-因为您知道，如果有机会重新做正确的事，您会做得更好。

我喜欢维护自己构建的代码。 这是我对用户的个人责任。 另一方面，维护我未构建的代码并忍受我没有做出决策的后果对我来说是非常痛苦的。

杰夫·阿特伍德
编程恐怖

许多软件开发人员将维护视为徒刑或至少是试用期。 他们上学去当软件工程师，但最终还是当了管理员。 对于“真正的开发人员”而言，维护工作既无聊又“令人沮丧”。

过去，我曾经做过软件维护，这实际上是我做过的最大的事情。

热狗在Jeff Atwood的博客上发表的评论
维护编程的崇高艺术 ，2008年10月

维护是艰苦的工作

Robert Glass在他的文章《 软件维护是解决方案而不是问题》中解释了为什么维护如此困难且不受欢迎。 维护是：

• 理智上的复杂–它需要创新，同时对创新者施加严格的约束。 维护人员必须在现有设计以及法规和治理限制内进行工作，他们必须谨慎维护与其他系统的兼容性，并且他们不能承担可能影响已经依赖该系统的客户的错误（这就是为什么一半以上的维护工作正在测试 ）。
• 从技术上讲，难度很大–维护人员必须能够同时处理一个概念，一个设计及其代码，并Swift将其全部提取。
• 不公平–维护人员永远无法获得维护人员所需的所有东西。 像好的文档或好的工具，或完成工作的时间。
• 不赢-维护者仅与有问题的用户打交道，而不是与高层赞助商就备受瞩目的战略项目进行讨价还价。
• 肮脏的工作–维护人员必须在肮脏的详细编码和调试级别上工作，而不是架构和创意设计，要担心如何构建和部署代码并确保其正确运行。
• 过去的生活–维护人员总是会遇到某个人在设计和技术方面的选择和错误，而不是解决新问题和学习新工具（这意味着没有机会填写简历）。
• 保守–维护的座右铭是“如果没有破裂，就不要修复”，因此维护人员必须忍受缺点，捷径和妥协，并尽最大可能完成工作。

但是，即使这是艰苦的工作，但维护工作的人们还是受到了赞赏，而且通常也得到了报酬。 高调的“软件架构师”职位和高薪是从事战略开发项目的华而不实的明星。 那么，为什么您-或任何人-要注意维护工作是否已转移到印度或罗马尼亚或其他地方？

维护太重要了

但事实是，维护太重要了，不容忽视-或外包。 这对组织来说太重要，对软件开发人员来说太重要。 维护–不是新开发–是大部分资金用于软件的地方，无论是否喜欢它，这都是我们大多数人将大部分职业都花费在这里的地方，无论我们是在企业系统上工作还是在构建在线社区或工作中在云供应商或收缩包装软件发行商处，或编写移动应用程序或嵌入式软件。

在当今的美国，有60％的软件专业人员（估计250万总人口中的150万）正在从事软件系统的维护工作（ Capers Jones，软件工程最佳实践，2010年 ），并且全世界从事维护工作的人数将不断攀升，因为我们不断编写更多软件，并且所有这些软件都需要得到支持和维护。 我们可以期待一个未来， 几乎我们所有人都将几乎所有的时间都花在维护上 ，而不是建造新的东西。

因此，我们必须改变人们对软件维护的看法，如何进行维护，尤其是如何进行管理。

糟糕的是我们如何管理维护

尝试使用基于ITIL服务管理或结构化软件生命周期标准（例如IEE-STD-1219 （ISO / IEC 14764））的正式治理模型来管理维护，或者将CMMi 成熟度模型应用于软件维护是无可避免的昂贵，官僚化和不切实际的。

在大多数组织中，维护是被动处理的，是日常业务支持中不可避免的必要部分。 管理层最关心的是最小化成本和麻烦。 为防止用户抱怨，我们要做的至少是什么？如何才能以最便宜，最快的方式完成这项工作？ 如果我们不能避免这样做，是否可以将其外包，也许可以节省一些钱，并解决其他人的问题，以便我们可以专注于其他“更重要”的事情？

这种短期思维会年复一年地持续下去，直到该组织在构建系统以及构建它的人员中所做的投资被完全用尽。 几年前，曾经关心做好工作的聪明人离开了。 该技术已经落后到已经成为另一个需要替换的“ 遗留系统 ”的地步。 只有少数人了解代码和技术，每次更改花费的时间更长，成本也更高。 技术风险和商业风险不断累积。 您的客户厌倦了忍受错误并等待他们需要的东西。 在某些时候，别无选择，只能将其丢弃并重新开始。 多么可悲，病态的浪费时间和金钱。

我们必须纠正这样的误解，即软件维护 会浪费 组织的精力 ，它会剥夺创新能力 ：创新只能在昂贵的新开发项目中进行 ，而花在您已经编写的软件上的工作就是浪费金钱 。 注意您当前的业务状况并不重要，并且将来也不能以此为基础。

在线，软件驱动的企业，例如Facebook ， Twitter和Netflix ，通过在现有资源的基础上进行投资，对人员和已经编写的软件基础进行投资，从而不断发展和创新。 这些公司的人们今天要做的许多工作是维护：在已有的代码中添加另一个功能，修复错误，使系统更安全，扩展以处理增加的负载，分析反馈数据，与新的合作伙伴集成，也许重写移动应用程序以便更快，更简单地使用。

这与其他人在其他公司所做的维护工作相同，而从本质上讲，该技术并没有那么令人兴奋。 不同之处在于工作的完成方式，管理方式以及人们的工作方式。 对于他们来说，这不是“维护”，而是工程。 无论开发新的东西还是支持已有的东西，开发人员都将受到重视，信任和尊重。 他们有责任和机会解决有趣的问题，与客户一起尝试和尝试新的想法，并查看他们的想法是否有所作为。 他们按照轻量级增量开发方法， 持续集成 ， 持续交付和持续部署 ，以及来自Devops的其他构想和自助服务工具组成的小型团队，以最少的文书工作和其他废话来快速高效地完成工作。

这些组织展示了应如何管理软件开发和维护：雇用可以找到的最好的人； 给予他们代理权和与客户合作并做出有意义的改变的机会； 向他们提供不断的反馈，以便他们可以继续学习并改进产品； 向他们提供所需的工具，并鼓励他们继续改进软件及其构建方式； 并使他们对系统（和公司）的成功负责。

这可行。 其他组织在做什么。 维护不是很糟糕。 这是我们如何思考它以及如何管理它的方法。 这是我们可以解决的问题。

参考： 维护软件插件–以及 JCG合作伙伴 Jim Bird在Building Real Software博客上可以采取的措施 。

翻译自: https://www.javacodegeeks.com/2013/08/maintaining-software-sucks-and-what-we-can-do-about-it.html