关于老系统的重构和优化选择

　　最近公司领导层脑袋发热要转java，干掉.net，所以碰到一个系统新的需求过来都要评估一下是重构还是原有的基础上修改

基于以上背景也就诞生了这篇文章：到底重构还是优化

我的建议是：工时决定一切

　　老系统重构会遇到2个问题：

　　1.业务的重新梳理

　　2.代码逻辑的梳理

　　业务的重新梳理：不用分析，大家做个系统的都明白，5年甚至10年的老系统业务梳理简直就是sheet，如果一个开发不想接这个系统，他一定会建议你去梳理业务（不用说，我就是那样的:-)）

为什么，因为要把业务梳理清楚至少要个10天半个月的，这段时间开发只要睡睡觉就能拿工资了，产品经理忙活了大半天没有沉淀文档，5年后又得重新来过。而且业务梳理是跨部门沟通，浪费的是两个部门的人的时间，算人天的话这成本可想而知。

　　代码逻辑的梳理：不管是重构一套还是优化，都要梳理代码逻辑，因为系统虽然重新开发的，但是老数据不能丢啊，不能升级下系统以前的数据就没了吧

　　重构的成本很高，那优化的成本就会很低吗？

　　这个要看情况，大部分情况一个优秀的程序员写的系统，优化的成本是很低的，注意，这里有个前提：优秀的程序员。我曾经碰到过企业的OA系统，里面的代码真的是sheet。方法名中英文混杂，不判断null，一个方法n个版本，fun1(),fun2(),funNew(),一个方法20多个参数，类A的方法调类B的方法，类B的执行又调类A的方法，问题是这样的代码难看点没有bug也就算了，问题是天天客户要找你为何页面按钮点不了了，为何导不了数据了，为何数据重复了。。。。维护这类系统让人怀疑人生，有个开发就是因为接了这个项目离职了。。。无奈作为tl只能自己上，没有人啊，公司不招.net，我能咋办，难道我也离职，没人要哇。。。对于这个系统，我就建议重构，因为维护的成本已经占用了一个

开发40%以上的工时。扯远了，优化的成本一般不高，只要一个系统平时的维护占用开发的工时不超过10%，也就是一周五天工作日不超过4个小时，我都建议优化。

　　当然，今天的案例有点例外，系统的代码也很乱，也没法看，上面的几个坏代码的要素也占了80%，页面按钮不能用，数据无法导出，反映慢，数据结构不合理，还有数据没有维护的页面，直接在mssql里硬编码进去的，原谅我又要骂人了@#￥@#￥#@￥%。这个系统用户都不使用了，所有本应用户自己能完成的事情都推给了开发，拉数据，维护数据等。没办法作为tl，在没有新人的情况，只能自己揽活了，系统不能用我给你重新整下吧，只要系统能用，开发也不用做非开发的活了。

　　揽活了，好评估下到底新开发还是优化呢。看了一下代码，虽然脏代码很多，但是主要问题只有3个：

　　1.组织架构是手动，不与ps系统同步，这个好解决，都不需要改程序，直接写个外挂（Python读取部门数据，对比系统的组织架构数据，同步缺的部门，更新重复部门的相关属性）

　　2.数据库链接超时是因为数据库处理该语句花费太长的时间导致超过了过期时间，默认是30秒

看了下代码造成该问题的是一个存储过程，在存储过程中拼接sql查询字符窜，搜索的条件字段没有加索引，表中的数据有5万条，然后又有很多表连接，这个问题也好解决

　　3.最后一个问题是手动维护的一个字典数据，理了下完全可以通过程序自动生成，只要不重复就行

　　4.用户新增的批量审批的需求，简单，只需要加个接口和sql

 

　　基于以上3点，果断选择优化，评估下最坏的情况大概10个工作日，其中包括5个开发日，3个测试日，1个写博客的日子，1个缓冲的日子，哈哈，如果选择开发新系统产品保守估计10个工作日100%投入，开发重头噜代码最少要30个工作日，而且还要兼容老系统，从这个角度讲一个给力的开发可以节省的工作量是不可估量的，各位老板，给好的开发涨涨薪带回来的回报也是不可估量的，不要因为跑了一个开发，新的开发来了重构一个系统，那就呵呵了

转载于:https://www.cnblogs.com/baojun2014/p/9084218.html