最近要做重构，有几个问题想请教开发大佬：
我负责的是软件模块之一，因此在交互性和独立性上有一定的分歧（Leader1：要能交互保证整体运行，Leader2：要独立，以后可能独立出去）
其实最后一点不太重要，比较关心前面两个，想多听听大家的想法！
石沉大海
重构个吉尔，又不是不能跑
最好不要重构，之前的一个生产系统花了好几十人一年时间重构，到最后客户不认可，导致直接把这一块的市场掉丢掉了 
刚开发没多久规模不大，而且原本的架构不支持未来扩展了
我去……但是我们这个还好，这个模块从头到尾我一个人负责，而且目前来看规模还不大，根据下一步的发展目标，重构是必要的，只是现在拿捏不好度。而且后面要构建开源生态……肯定得把代码写得让人好入门才行
软件重构的过程。首先需要定义重构的目标，然后收集一下重构的理由，以及目前可以被重构过程使用的信息资产。
如果你的重构目标的确是优化软件架构，那么就可以从软件的日常维护出发，总结看看日常所遇到的问题。
可维护性、可扩展性和开发效率之前其实没有很大的直接制约关联关系。它们之间更多的是相互影响的关系。
可维护性其实是要求更清晰明了的代码结构，更短的方法调用，更多的提取公共函数，要求代码有更少的个性化的东西。可扩展性则是要求代码在一个共同的框架下协作，以一定的协议抹除个性之间的差异。开发效率其实更主要的是受人的因素影响，只要软件代码的复杂性不是很高，客观因素对于开发效率的影响其实并不大。
所以根据你的描述，你所需要的实际上是一个直接简练的、没有过多层级和范式约束的软件架构。
对于数据结构来说，没有太多可以遵循的方法论，其实也是只需要仿照常用的数据库范式设计即可，但是还需要保证一定的信息冗余，用来方便数据的访问和操作。
对于你的第三个问题，我的观点是一个模块只需要做好自己的事情即可，交互性是接口和协议定义的，不是模块应该关心的事情。一个模块只需要要求接口和协议提供它正常工作所需要的数据即可。
谢谢佬~
能用就不要动
能不动就尽量不要动
没办法，必须得扩展
领导同意，并且领导自己愿意承担失败的后果而不是让你背锅也不是不可以，但重构可不是重写，重构可以渐进的进行，比如项目模块划分不合理可以抽一周时间暂停需求开发搞一搞，某个流程写的有问题可以在需求涉及到该部分时同时调整，向领导多要几天时间，讲明原因，这就是能用就不要动，不是不动
好，明白！
以后得事，以后再说。
哈哈哈哈哈哈哈
强水一下，抛砖引玉。
其实这个问题个人理解算是可以分成三个：
1.业务代码逻辑重构
2.业务属性剥离
3.程序设计扩展
以上几个问题，第二点应该是优先考虑的。
业务属性剥离，一般需要定义几个方面
1.定义输入，输出。入参需要什么，出参需要什么
2.交互方式（http，rpc，mq等）
3.封装sdk，如有必要
这过程也需要对原体系进行分析，梳理对象，状态流转等
代码逻辑重构，因为我主要语言是java，以java为例
1.公共代码抽取
2.设计模式
3.设计缓存以减轻重复查询，或者重复解析操作
程序的可维护性、可扩展性和开发效率
1.可维护性这块主要个人理解主要看代码质量。代码规范性，文档完整性，这个用心一般不会很差
2.可扩展性一般可以参数化配置，hash表入参（如工作流activity框架的传入hash结构的参数），占位符替换等等…
3.开发效率主要是在前期的设计过程是否详尽，如果设计较为详细，开发效率自然比较高
就这样。 
核心方法：
Ctrl+C，Ctrl+v