软件项目生命周期与如何推动重构

软件项目生命周期

任何事物都是有生命周期的。
项目发展过程也一样。
一般来说，一个应用系统，如果业务一直在发展，系统本身也应该在发展。
最开始的时候，大师出场，带着小弟，精心设计一个系统，呕心沥血，代码干净，模块清晰，文档齐全，性能很高。
一切都是看起来很好的样子。

业务在发展，系统本身也一直在修改，添加新功能，改进旧功能，
而且，发展过程中，老系统的很多bug被发现，也添加了很多代码， 就是一个个的补丁，
就算初始的系统，很nb，很华丽，随着时间的推移，补丁的增多，
特别是IT软件开发高达30%+的人员流动率，老的人走了，新的人加入进来。

系统慢慢的开始老化，变烂, 慢慢的系统变成bad smell了。

这时候，问题出现了。
1、系统经手的人，修改的次数很多，代码量比较庞大，
2、有很多代码可能是无用的，但是没人掌握全部代码，
3、很多修改，没有有效的注释和文档，说也说不清楚了，牵一发而动全身，
4、系统经常反复出bug，性能下降，花费在日常维护性上的工作量非常大，
5、新的人员加入团队，学习周期较长，接手维护很困难。

整体说来，系统本身已经out of control， 变成一个巨大的无人能控制的怪兽。
一般说来，软件研发管理做得差的公司，一个10万+行代码的项目，一直维护，2-3年就会这样了。
好点的公司，5年也差不多了。

互联网的项目，因为业务变化快，迭代周期更快。
从软件生命周期上来看，这个系统进入老年期了。

如何推动重构

刚才说了软件的生命周期，
再说说为什么领导层不愿意重构：还是成本问题。
这个工作量，至少不低于原系统开发的一半周期。
领导们一般只关心眼前短期利益。长期利益和潜在利益，他们看不到。

可是呢，领导不会同意重构。
重构，对他们来说，就是把现在的东西，又实现了一遍。。。
在领导看来，表面收益是0，成本却很大。
所以，直接的重构，领导不会同意。

除非是比较强势的领导，比较有前瞻性、比较有进取心，要做好最大的领导。

既然知道了领导为毛不同意重构，其实也就基本有了突破口。

1、把重构的好处，特别是长期的好处，整理清楚，列出来。
比如，代码里，现在有多少坑，性能有多低，维护有多困难，修改一个地方，牵扯多少地方，有多少地方没有人搞清楚，代码大概有多少冗余量，现在经常出bug率是多少。
如果改造，我们能代码量减少到多少，能培养几个对整个系统都能掌握的人，性能能提高多少，维护成本能减少多少，添加新功能、新成员加入团队上手时间，能降低多少。

这些重构的优点，都摆出来拿出数据。让领导去判断。
如果确实需要重构，有足够的好处，领导基本会同意。
特别是如果现在旧系统出过几次事故之类的，更好说服领导了。
这个是直接命中目标，就能推动这个事情。

2、如果领导还不同意，还可以曲线救国。我们可以名义上不重构啊。

我们的系统，一直在发展，改进现有功能和加新功能。我们可以在每次加新功能的时候，把新功能搞清楚，

抽出来，做到一个新的系统里。相当于在一家旧飞机旁边一点点的造一架新飞机。
然后，只要处理的足够好，这个增量迭代的方式，即重构了旧系统，也做了新功能，影响最小。效果非常好。

很多集成旧系统类的项目，都建议这么做。
一般情况下，做一部分的时候，新做的这些模块的优势就展现出来了。
后续的工作，领导就会比较支持了。
反正你也没怎么耽误他的事儿。

我在x宝的时候，
先后用过这两种方式。
第一个系统，40万行代码，重构后只有10+万行。
第二个系统，我负责主体核心部分的迁移，灰度发布后，交给别人了。

第一个项目结果：
1、40w-10+w，性能提高了差不多一个数量级。
2、培养了5个对整个系统都能控制的人。
3、模块非常清晰，各种跟踪统计监控管理工具，也顺便做了进去。
4、新人上手以前需要2周，现在2天就够了。
5、各种代码规范，设计文档，也都补齐了。
起码可以再撑个5年了。
当然这个项目，很大一个原因还是我们领导，当时很有魄力。
虽然他不太懂技术，但还是放手让我们去做。
这两个项目做完不久，参与项目的主要人员都level up了。