Vineet Sinha观察到，在各行业的企业组织都出现了相同的情况。生产力下降，代码库太具有挑战性而无法维护，更有甚者，开发商把更多的时间花费在会议上而不是工作上。虽然他可能无法改变会议的必要性，但是Sinha认为，提高Java应用程序的模块化可能会简化代码库并挽回生产力。

　　Sinha是Architexa的共同创立者和首席技术官，他总是可以走在最前端、指导研发团队、管理产品架构、克服性能问题，并且整合不同系统。Sinha清楚地展示了，波士顿EclipseCon 2013会议上Java开发人员和构架师对大型遗留Java应用进行模块化处理的过程。

　　在他的演讲中，Sinha为企业构架师提供了四个步骤，这将会提高遗留Java应用程序的模块性。　　

步骤1. 构建架构图

　　架构图的重要性就在于，让每个人都参与到项目中。参与到项目流程中的个体都将会明白不同代码库的主要结构。这适用于不同的部分——开发、质量评价、运维和业务，同样也适用于同一部门的不同开发人员。Sinha指出：“如果你让10个不同的开发人员构造一幅代码库图，你会得到10幅不同的图。独立的开发团队可以引用不同名称的同一结构。这种困惑可能引起团队成员的重大分歧。”

　　当工作进展很顺利的时候，构建架构图基线的过程可以通过持续一、两个小时的单独会议完成。在小型团队中，核心开发人员也许能够独立的起草一个架构图。当与其他人讨论对构架图的更改时，可以为开发人员提供一个空间。在大型组织中，重要的是所有利益相关者的代表性。Sinha建议让所有团队领导在一个房间内。他说：“让他们一起画架构图，把主要的部分画在一张纸上。”　　

步骤2. 合并架构图

　　一旦开发人员或团队领导对代码有自己的想法，这时候就应该在其中做出妥协来选择一个较好的架构图。一个成功的现代化项目需要一个独立的、易查找的文档，让利益相关者对现有的架构图有一个普遍的、高远的认识。这张架构图会使他们有更多的合作讨论他们必须要做的工作，而不是争辩，。

　　如果对组件用来做什么和适合哪里有高度统一的意见，那就执行统一的意见。要专注于顶级大组件。建立一个熟悉这些组件的团队，描述清楚组件间的连接。找出不同名称独立运行组件的共同特征。该流程会指出某些地方较小的变化，例如合并几乎相同的“垃圾”和“删除”功能。这样可以简化代码，使团队更加紧密地参与到维护和模块化的应用组合工作中。　　

步骤3. 转移现有代码

　　Sinha说，中途开发人员可以为自己小小庆祝一下。如果开发团队非常顺利地完成前两步，那么现在他们就会很清楚地了解现有的系统及所需。谈论系统集成问题时，开发团队也会具备强大的共享词汇表。现在可以使组织现有的代码更加智能化。

　　Sinha说，例如，客户端过滤和服务器端查询功能可能会做同样的任务。他解释道：“一旦开发团队找到了解决方法，他们可以共用一个名字，让过滤和查询功能结合的更好。”

　　完成架构图后，企业架构师就可以分类组织代码。在这方面，开发团队应该做好准备，使文件更接近最终要完成的任务。Sinha认为，这样开发团队就会有巨大的进步。他说：“该问题使他们开始关心自己，代码变得有条理，就会检测出漏洞，更容易理解漏洞。”　　

步骤4. 打破不良的依赖性

　　这是重要的一步，需要一个背景和对专家的依赖性。Sinha说，该任务不能交给没有经验的开发人员，因为它需要很多的经验。修复命名约定确保应用程序编程接口的一致性十分重要。正确命名是梳理好事情的重要部分。重要的是要记住,某些步骤应该要保密。

　　掌握这方面的技能实在是有些困难，但是却很有价值。Sinha建议，高级开发人员采取依赖注入编码，在一个简单的项目中或假设的代码库中将无框架的代码反转。他说：“这些工作太困难了，自己完成不了。在代码库狭小的空间中完成这些会非常舒服。”

　　若要应用到实际代码库中，对其进行改变就会非常谨慎。从表层开始，然后深入到代码，一层又一层的递进。要记住编译时依赖与运行时依赖之间的差异。这可能对数据库依赖来说非常重要。

　　除了依赖性，还需要关注些其他具体任务。例如，Sinha认为，类加载器有自己的规律，需要一个专家开发人员参与到其中。他警告说：“该代码非常复杂，其中隐藏了一个非常危险的结构。相应的改变会使没有经验的开发人员避免该情况发生。”他建议，让有经验的团队成员分享他们的经验，并通过自动测试和代码审查对代码进行维护。