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

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

 

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

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

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

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

    4、  流程的规范程度(开发和测试)。

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

 

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

 

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

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

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

posted on 2012-08-13 17:02  Martin Stallman  阅读(201)  评论(0编辑  收藏  举报