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

关于⽼系统的重构和优化选择
最近公司领导层脑袋发热要转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个⼯作⽇，⽽且还要兼容⽼系统，从这个⾓度讲⼀个给⼒的开发可以节省的⼯作量是不可估量的，各位⽼板，给好的开发涨涨薪带回来的回报也是不可估量的，不要因为跑了⼀个开发，新的开发来了重构⼀个系统，那就呵呵了。