MVC三层，换皮风险小，而且只换皮，我们一般不会叫系统重构。重构都要动逻辑层架构，

举个小架构调整的例子，比如原来是服务器消息回来，直接分发到页面CV层处理并实现，维护比较高，现在改成接口层接受服务器消息，解析层完成JSON解析，解析完后消息层发送消息，数据使用层通过监听获取通知，通过接口获取数据使用。如此维护接口层和解析层就好。

一般重构都是不动功能，如果动功能又动架构，那就是重做。而且也要看重构目的是什么？如果是为了提升代码可靠性、扩展性、提高开发效率等，那基本都是不动功能的。

我们之前将游戏引擎由c++，换成了JS，方便终端人员开发，就做了重构，封装原有引擎，建立JS接口，JS层建立新引擎，为了提升效率，通过脚本可以自动创建新类及MVC配套的物理文件，如此所有的后续游戏页面开发，都用统一的代码标准进行。功能不变，就这样半年多，后续还有优化，公司挺不愿意的，认为业务上啥也没做。在原有成熟的基础上重构是相对稳定的，如果有新东西，没开发出来都不知道风险性如何，所以，重构不建议新功能。重构以后稳定了再加新功能。我们原来重构为了敢时间，还减过功能……

哦对了，重构一般是动架构的。您说的这种得具体看你们遇到的问题，和重构的目的，因为没看到代码，也不知道你们具体是啥，不好说。当然也有没事找事的，不能让技术闲着的；反正非技术的业务和管理层也看不懂[捂脸]，所以高层或业务无法评判有没有做的必要。

#产品经理挑战赛# day3

个人认为如果主题是「系统重构」的话，功能完全不动是不合理的。

首年从字面意义来理解，重构：重新构造，自然是要重新来设计，如果系统功能都没有做任何更改，那又叫什么重构呢？如果只是做了页面UI的重新美化，我更愿意称之为换肤。

再从系统本身来说，系统需要重构，自然是因为当下某些功能或者能力满足不了业务或操作需求，重构的核心诉求就是优化系统功能和业务功能，如果只是换个皮肤，又怎么起到重构的作用，达到重构的目的呢？

当然如果是因为企业内部KPI需求，换肤重构也不失为一种提现工作量的一种方式，反正，领导也不懂代码，你说是不？

 #产品经理挑战赛# day5

先回答问题：系统重构，所有功能都不改变合理吗？

系统重构要分功能性重构、业务性重构以及系统性重构。所以每次重构的时候我们分清楚这次重构的目的的时候。

是功能复杂臃肿，需要精简优化功能？还是业务耦合过多，需要业务拆分？还是说技术、设计模式老旧，无法有效率的支撑现在的模式？

反正就是重构不一定是看得见的重构，还有业务、代码等等上面的重构。

只是可能大多数人一说到重构就是以为是页面上看得见的罢了。

前端看到的只是展示的东西，背后的逻辑和架构才是最重要的，重构在这一块也是最难的。有很多系统可能是几年前已经做好了，用的框架可能是比较老旧，也有可能已经不再更新了。所以通常都是在原有的模块、功能基础上先对整个架构进行重构，然后再对页面样式进行重构让用户在体验上更好。

#产品经理挑战赛# day9

首先，这个需求就提报的不合规，因为重构的概念就是优化去做提升，去做的更好，这里必然涉及到代码架构、功能应用、界面交互三部分。

其次，沟通的方式不对，leader的功能不让动，是指哪些？如果动了不增加太多工作量是否可以？比如6位验证码字母+数字，改为4位纯数字，是否可以？

还有就是优化看排期进度，优化的最终目的是做提升，这次先优化代码，下次再优化功能是否可行？还是可以交叉操作？leader不让动的原因是想要集中完成还是他只管技术部分？

如果这个事情是我来做

1、先和研发沟通清楚，架构沟通的整体情况，当中想要做一些穿插，在什么阶段比较合适。

2、其次同时要准备好跟随迭代的内容，按照重要的优先级做排序，协商穿插的时间点和节点。

3、安排里程碑进度做排期，最优实现结果，然后反馈目标、节点、消耗。

#产品经理挑战赛# day5

我之前也做过若干个系统重构，分别说一下想法。

1、技术主导类的，系统内部的重构。比如之前代码冗余度较高、系统之间耦合较大，性能不够，代码框架老旧、更换语言。举个栗子：我当时做登录注册的时候，系统性能压到1w多tps的时候，感觉就扛不住了。这种情况下，开发要重构代码。此时我只需要梳理下目标、基础流程就好。这种感觉是最无力最茫然的，也是题主的这个状态，不让动，不能动。还经历过从C#换成java的一次，也是让人胆战心惊。

2、产品和技术共同主导的。当时做预售的时候，在高并发、高复杂度的场景下（退货、增加活动库存、减少活动库存等等），我们有时会有超卖风险，但现有方案无法解决。故约着对方系统进行重构资格管理的逻辑。当时我们的目标比较明确，就是为了解决现有的超卖问题，所以功能也没做删减调整。因为产品全程参与的对外交互和重构，故当时深入的了解了各个系统的架构切分和系统交互，出了很多分系统流程图。对我来说，这次重构对系统认知更多了。

3、产品主导的。比如对功能归集，逻辑重新梳理，产品二次定位等等。当时做以旧换新的时候，一开始我们处于承接前中后台的功能，后来重新切割定位，定位成前台，那么此时这种重构就是大刀阔斧，删除冗余功能。

我将技术主导的称之为换骨，外面看还是一个人，但是里面的骨架可能都变得不认识了（为了后续的成长）。产品和技术共同主导的换血肉。外面可能看到了可能是面色红润了一点（解决一些业务问题）。产品主导的是整容。对于外人来说，可能就像看一个新的系统。

换骨是为了更好的支撑业务，换血是为了解决痼疾，整容则是为了好用、易用。但每一种都有其意义。

得看你重构是为了解决什么问题，比如：

1、视觉体验停留在10年前

2、当时用户较少，技术架构设计不合理，当初没有考虑扩展

通常来讲视觉体验我们不称之为重构，重构多发生在产品历程中因为业务的发展，在原有的基础上新增或者调整了一些功能，或者因为业务的发展，技术框架日驱不能满足。重构的目的不就是未来能够更好的服务于用户/业务么？

就我们之前的经验而谈，我觉得有意义，我们那会（主业务已基本成型）属于技术架构的重构，就是说某些表之前设计的时候考虑的不是特别全，导致数据查询比较慢等一些原因就需要重构，重构的时候技术总监会从全局解决一些目前遇到的问题，如果说要加一些其他的东西，节奏上会不太好把控，我个人感觉提问的应该是个中小型公司

合理，如果你是个产品就多跟技术聊一聊，如果你是个技术，可以看看产品机会

虽然很水，但是是实话，具体问题具体分析

具体产品具体分析，不是一概而论的