对于项目维护的思考
May 12, 2016 · 1 minute read · Comments开发
对于项目维护的思考
漫谈。 程序写多了，对于一个项目的维护久了，产生了一些特别不一样的想法，写下来，与人念叨念叨。
实际开发
说维护，自然要从实际开发说起。 特别的聊一下加粗的这两个字，实际。 实际开发中，总是会有状况发生的，这是定律，所以，对于实际开发来说，我第一个想法就是短，准确说，别做太多事让整个开发周期拉长。短是方便控制，同时也便与紧急处理。实际落实过程中，总是会出现这样或者那样的妥协，我们尝试了很多办法去减少状况的发生，刚开始还不错，但随着这样或者那样制度的复杂度加深，效果却越来越小，甚至反弹。只能说，通过外力去减少异常状况的发生，有用，但没有那么有用。 所以，把目光转回来。 如何紧急处理紧急问题，成了实际开发中的最大的问题。就如我刚才所说的那样，这其中总会掺杂着这样或者那样的妥协，这篇是技术文，暂时抛开产品的专业性，就技术而言。如何紧急处理问题？ 1. 减少复杂度。（这是最最重要的一条）在绝大多数情况下，我们处理的问题本身的复杂度，不会超越技术本身的承受力。（相信我，超过的问题，一般都会有更牛的人在前面帮你开拓了）所以，大多数看起来复杂到不可控的问题，都是由于我们的认知不够，有可能是认知缺失，也有可能是疏忽，所以看起来很复杂。但实际却经不起推敲。所以，减少复杂度，我给的建议很简单，找到相关的人，坐下来，重新梳理之后，做减法，减掉不必要的复杂选项后，再做修复。减少复杂，不代表肯定是减少功能，这几年和产品的博弈过程中，每次找产品，产品都觉得是我在减功能，囧。重申一遍，梳理逻辑才是重中之重。 2. 解耦。紧急问题的处理，总会有那么一种‘写死’的方案，或者说，总有那么一种成本低但耦合度高的方案可以勉强解决问题。千万不要这么做，这就是‘泥石坑’（人月神话），除非你不考虑下个版本，否则，这只能让你下个月的工作大大增加。因为，你不得不用一个很高昂的成本来弥补你这个时候偷的懒。 3. 尽早寻求帮助。紧急的问题加上时间的压榨，很容易让身处‘局里’的人盲目或者过激。不理智是留下遗留问题的根源，这里我自身也犯下了好几次错误。不得不说，坦诚承认，然后及时向他人寻求帮助是最好的对策，保证项目是首要，至于那一点点羞耻心真的不重要。因为纸包不住火，维护的时候终究还是要面对的。
其实，说了这么多，感觉都跑题了。其实，我想说，项目维护时流的汗水，都是开发时，你处理紧急问题时脑子进的水。 不顾以后的维护，只图解决眼下的问题，终究是要偿还的。
实际维护
维护或者优化。最重要的是：千万改完一个bug，又改出来一个。 然后，这个事情基本上是我所见到的实际维护过程中最高频率出现的事情之一。而其中大多数原因，就是缺少思考的修改了原来的代码。这么讲的话，难道维护或者优化的时候修复一个bug，要来来回回的思考和判断逻辑才能改原来的代码吗？全部这么做的话，成本岂不是太过于高昂了。 不好意思，的确是这样的。维护时期修复一个问题，要比开发时期困难很多很多。在一个勉强称得上稳定的系统上（默认上线的版本是较为稳定的版本），是它变得更加稳定和可靠是一件很难得事情。因为任何的修改的前提是，不能破坏原来的稳定。一句，不能破坏原来的稳定，就是最大的成本。 同时，维护还要尽量保证后来的维护或者优化能顺利进行，所以刚才的123点同时也是要注意。 也再说几点我的心得。 1. 时间是最大的成本。相信没有真正的维护时期，都是或多或少掺杂着新的开发，所以所谓的维护时间，并没有想象中的那么长。同时，人们总有种倾向，会认为新开发的优先级会高于旧维护的，毕竟，一个已经有了只是存在问题，另一个还没有。这种倾向会传染，让我们不自主的给维护更少的时间。 2. 拒绝拖延。程序开发里有一个不成名的定律，但凡说，以后改的问题，最终也没有改。说下一次就修复的事情，再也没有出现过下一次。这是个很伤心的事情，人始终不断的尝试或者做新的事情，的确能获得很多，同样，在修复和更改中，也能获得同样多，但却很少有人这么做。鸡汤说完，说实情。如果旧的问题始终不处理，会导致新的功能的不完整，连带出来很多新的问题。很少有功能或者说需求是完全和旧版本脱离的，自然使用也要不断使用旧版本中已经完成的功能，所以，拖延只能导致不断前进的步伐陷入‘坑’，举步维艰。
随便写点，先写这么多吧。