程序猿的吐槽三——改进还是不改进

这个吐槽来源于实际项目中一个关于稳定性和效率的争论。

 

    线上运行系统有一个矛盾的点，就是如果要对其进行修改，就会引入潜在的问题，进而影响系统的稳定性，当然这只不过是一种潜在的风险。而这种潜在风险的高低有一些影响因素。

    1、  对现有系统的熟悉程度

    2、  对修改技术的掌握，比如重构技术等（重构技术对于修改软件来说非常重要，如果有非常高超的重构技术，那么在对系统不是很熟悉的情况下依然能修改出来高质量的系统，也就是说高的重构技术可以弥补对系统的不熟悉）。

    3、  现有系统的架构，如果现有系统的架构比较好，耦合性很低。那么新修改就大大降低了影响范围。

    4、  流程的规范程度（开发和测试）。

    5、  开发人员的责任心和细心程度（在所有的工作中，一定首先考虑“人是不可靠”的这一前提，然后在这一前提之下做好其他相关工作。这样人如果是可靠的，那么事情会处理的非常顺利。当然事情还是人做出来的，所以最后一条我引入了人的责任心和细心这一因素。还是要相信有一些人可以干好非常细致和繁琐的活而不粗心）

 

     某天听到两个人在吵这件事情，一个激进派觉得现有系统的一些缺陷影响系统的性能，需要进行修改。而另一个属于保守派的人则认为，你的修改可能会引起系统的不稳定，导致系统出现故障。为修改这一个问题不划算。两个人争的脸红鼻子粗。

 

     对于任何一个系统来说，如果要修改，则制定一个稳定性和高效率之间的一个可接受比例，这个比例的制定根据对系统的了解情况和系统的质量来决定，根据以往的经验可以做一个估值，比如我一个修改能提高了50%的效率或者性能，但是这一块的修改会影响到30%的核心，那么就应该考虑修改。经过规范的流程和优秀的技术可以将影响降低很多。

     所以，结论就是，在保守（稳定性）和激进（效率）之间根据自己系统的情况设定一个估值比例（改还是不改的估值）。当超过这个比例之后以稳定性为重而考虑放弃高效率，如果在这个可允许的比例之内，则不用害怕影响稳定性而显得非常保守，以至于不敢对系统进行效率上的优化和改进，这样日积月累终将会导致系统虽然很稳定，但是已经没法使用了。

    其实在上面的这个估值过程中，还有三个至关重要的因素，一个是领导是否属于保守者，另一个是用户是否属于保守者（固步自封者），还有一个就是真出问题了责任能否担的起。