大家都不喜欢维护遗留项目，我也不例外。命运总爱跟人开玩笑，最近一个遗留项目正好落到了我手上。虽然在这个项目上工作的经历并没有减少我对遗留系统的厌恶，反而让我对当下所采用的流程与实践有了更深刻的认识。
我为自己所在的团队感到自豪，因为我们遵循了许多业界最佳实践：
当然，一切并非尽善尽美。合并请求中偶尔会出现一些无关痛痒的建议和讨论；运维团队有时也会搞砸一些事情（至少在我们开发人员看来是这样）；而产品负责人也时不时催促我们加快推出某些“简单”的新功能……总的来说，情况还算不错。
由于团队表现出色，公司决定将我们的开发效率借调给另一个由其他部门负责的产品。令我们略感失望的是，这个项目不仅使用的是较老版本的Java，其代码风格也与我们的习惯大相径庭。
任务要求我们添加几个简单的监控指标，比如应用是否正常运行、运行时长、数据处理是否足够迅速等。由于项目正处于维护模式，已经有段时间没有添加新功能了。按理说，添加这些指标对我们来说应该是小菜一碟。
然而，当我们卷起袖子开始工作时，首先发现这个项目竟然使用了一种非常古老的构建方式——Ant构建文件。那是一种庞大的XML文件，详细描述了如何构建整个项目：从编译、测试到打包，每个环节都必须显式配置，包括源码路径、目标路径以及资源位置。过去，这种做法在许多编程语言中都很常见：写好一个构建文件，复制到每个新项目中，再不断调整直至适应新项目需求。
例如，一个简单的“Hello World”项目的Ant构建文件可能如下所示：
<project> <target name="clean"> <delete dir="build"/> </target> <target name="compile"> <mkdir dir="build/classes"/> <javac srcdir="src" destdir="build/classes"/> </target> <target name="jar"> <mkdir dir="build/jar"/> <jar destfile="build/jar/HelloWorld.jar" basedir="build/classes"> <manifest> <attribute name="Main-Class" value="oata.HelloWorld"/> </manifest> </jar> </target> <target name="run"> <java jar="build/jar/HelloWorld.jar" fork="true"/> </target> </project>
难道就没有更便捷的方式吗？正因如此，“约定优于配置”的理念应运而生。这一理念主张：开发者只需关心那些偏离约定的特殊情况，而现代构建工具正是基于这一思想，通过提供可覆盖的默认配置，免去了重复配置的麻烦。正因为如此，大多数Java源码统一存放在 src/main/java 目录下，而编译后的文件则放在 target 目录中，避免了繁琐的重复设置。
src/main/java
target
这一发现启发了我们：或许同样的原则也能应用到我们当前项目中的应用配置上。面对一个庞大且大部分数值雷同（如应用端口）的配置文件，采用默认值机制无疑能让配置文件变得更精简。
回到遗留项目，我们顺利构建并打包了应用！那枯燥的部分终于过去，可以安心开始编码了。但问题随之而来：如何将我们负责监控的指标组件嵌入到这套老旧的代码库中？在我们的常规开发框架中，这一切通常是自动处理的，因此我们一度认为这毫不费事。
但实际上，将指标组件“注入”到遗留代码的各个角落，最佳方案是什么呢？初看起来，单例模式似乎是最简单的选择；不过，开发社区普遍认为单例是一种反模式。为什么呢？毕竟，我们钟爱的某某框架不也依赖单例吗？如果不是，那它到底采用了什么机制？依赖注入究竟是什么？其底层又是如何运作的？
这一连串问题促使我们重新审视那些一直视为理所当然的基本概念。虽然在这种情况下使用单例并非最糟，因为代码大部分缺乏单元测试，但要让我们心安理得，代码必须经得起推敲。经过尝试，我们最终采用了一种不同的方案，写出了既简洁又清晰的代码——既没有依赖单例，也未引入多余的抽象层。
项目的最后一步是部署，只有部署成功后才能进行测试。但问题来了——这一次，我们既不负责部署，也不负责测试。部署工作由运维团队完成，而测试则交由专门的测试团队。为什么开发者就不能全程掌控，从开发到上线，而要先提交工单，再等待其他团队的配合呢？
首先，由于代码测试覆盖率不足，手动测试不可避免；其次，公司的基础设施也不允许我们自行部署应用。
这一系列经历使我们开始思考职责分离的原因，以及现行模式为何更为合理。事实证明，这个项目的任务交付时间和迭代周期远远超过平时（通常几天就能交付的工作，此次竟拖延了数周），这无疑验证了分工合作的必要性。
到了月底，我们的监控指标终于在生产环境中顺利运行。虽然我对遗留项目的看法依旧——我仍然讨厌它们，也不奢望你会因此改变看法——但这段经历给了我们宝贵的启示。
我们无法选择所分配到的项目，但我们可以调整对待遗留系统的态度。与其心存无奈，不如把它当作一个提问、学习与成长的机会。通过了解过去的做法及其局限，我们不仅掌握了当下的最佳实践，更获得了背后历史的宝贵经验。
一旦你积累了这种深厚的知识，其他开发者自然会认可并信赖你的专业能力。如果你希望成为这样的人，就得勇于钻研那些看似繁琐的遗留项目。
原文：https://www.infobip.com/developers/blog/seniors-working-on-a-legacy-project
作者：Alen Kosanovic
评论删除后，数据将无法恢复
没有处理过遗留项目，别自称资深工程师
大家都不喜欢维护遗留项目，我也不例外。命运总爱跟人开玩笑，最近一个遗留项目正好落到了我手上。虽然在这个项目上工作的经历并没有减少我对遗留系统的厌恶，反而让我对当下所采用的流程与实践有了更深刻的认识。
我为自己所在的团队感到自豪，因为我们遵循了许多业界最佳实践：
当然，一切并非尽善尽美。合并请求中偶尔会出现一些无关痛痒的建议和讨论；运维团队有时也会搞砸一些事情（至少在我们开发人员看来是这样）；而产品负责人也时不时催促我们加快推出某些“简单”的新功能……总的来说，情况还算不错。
穿越回Ant时代
由于团队表现出色，公司决定将我们的开发效率借调给另一个由其他部门负责的产品。令我们略感失望的是，这个项目不仅使用的是较老版本的Java，其代码风格也与我们的习惯大相径庭。
任务要求我们添加几个简单的监控指标，比如应用是否正常运行、运行时长、数据处理是否足够迅速等。由于项目正处于维护模式，已经有段时间没有添加新功能了。按理说，添加这些指标对我们来说应该是小菜一碟。
然而，当我们卷起袖子开始工作时，首先发现这个项目竟然使用了一种非常古老的构建方式——Ant构建文件。那是一种庞大的XML文件，详细描述了如何构建整个项目：从编译、测试到打包，每个环节都必须显式配置，包括源码路径、目标路径以及资源位置。过去，这种做法在许多编程语言中都很常见：写好一个构建文件，复制到每个新项目中，再不断调整直至适应新项目需求。
例如，一个简单的“Hello World”项目的Ant构建文件可能如下所示：
难道就没有更便捷的方式吗？正因如此，“约定优于配置”的理念应运而生。这一理念主张：开发者只需关心那些偏离约定的特殊情况，而现代构建工具正是基于这一思想，通过提供可覆盖的默认配置，免去了重复配置的麻烦。正因为如此，大多数Java源码统一存放在
src/main/java目录下，而编译后的文件则放在target目录中，避免了繁琐的重复设置。这一发现启发了我们：或许同样的原则也能应用到我们当前项目中的应用配置上。面对一个庞大且大部分数值雷同（如应用端口）的配置文件，采用默认值机制无疑能让配置文件变得更精简。
被我们视为理所当然的事情
回到遗留项目，我们顺利构建并打包了应用！那枯燥的部分终于过去，可以安心开始编码了。但问题随之而来：如何将我们负责监控的指标组件嵌入到这套老旧的代码库中？在我们的常规开发框架中，这一切通常是自动处理的，因此我们一度认为这毫不费事。
但实际上，将指标组件“注入”到遗留代码的各个角落，最佳方案是什么呢？初看起来，单例模式似乎是最简单的选择；不过，开发社区普遍认为单例是一种反模式。为什么呢？毕竟，我们钟爱的某某框架不也依赖单例吗？如果不是，那它到底采用了什么机制？依赖注入究竟是什么？其底层又是如何运作的？
这一连串问题促使我们重新审视那些一直视为理所当然的基本概念。虽然在这种情况下使用单例并非最糟，因为代码大部分缺乏单元测试，但要让我们心安理得，代码必须经得起推敲。经过尝试，我们最终采用了一种不同的方案，写出了既简洁又清晰的代码——既没有依赖单例，也未引入多余的抽象层。
开发者角色的局限性
项目的最后一步是部署，只有部署成功后才能进行测试。但问题来了——这一次，我们既不负责部署，也不负责测试。部署工作由运维团队完成，而测试则交由专门的测试团队。为什么开发者就不能全程掌控，从开发到上线，而要先提交工单，再等待其他团队的配合呢？
首先，由于代码测试覆盖率不足，手动测试不可避免；其次，公司的基础设施也不允许我们自行部署应用。
这一系列经历使我们开始思考职责分离的原因，以及现行模式为何更为合理。事实证明，这个项目的任务交付时间和迭代周期远远超过平时（通常几天就能交付的工作，此次竟拖延了数周），这无疑验证了分工合作的必要性。
通过旧实践理解现代方法
到了月底，我们的监控指标终于在生产环境中顺利运行。虽然我对遗留项目的看法依旧——我仍然讨厌它们，也不奢望你会因此改变看法——但这段经历给了我们宝贵的启示。
我们无法选择所分配到的项目，但我们可以调整对待遗留系统的态度。与其心存无奈，不如把它当作一个提问、学习与成长的机会。通过了解过去的做法及其局限，我们不仅掌握了当下的最佳实践，更获得了背后历史的宝贵经验。
一旦你积累了这种深厚的知识，其他开发者自然会认可并信赖你的专业能力。如果你希望成为这样的人，就得勇于钻研那些看似繁琐的遗留项目。
原文：https://www.infobip.com/developers/blog/seniors-working-on-a-legacy-project
作者：Alen Kosanovic