因为手上的项目最近在进行验收，所以需要根据验收的问题进行修改，也就是根据验收报告修改系统的bug或者功能缺陷。但是经过几次验收都没有通过，主要原因是因为另一位搭档的模块总是出问题，后来经过一次验收之后，我决定自己亲自内测他的模块，结果我也测出了很多问题，把这些问题跟他一讨论发现要修改这些问题确实牵涉的地方太多，而且解决了一个问题会导致其他的新问题，后来我发现他的功能之间的耦合度太大，而且对于一个功能的流程设计自己前后都说不通，有的地方前后矛盾，也就是说这个功能在他做的时候并没有明确确定这个功能的流程，所以导致后面功能出现的意外情况，他自己都不知道这样是不是对的，模棱两可，表面上感觉是怎么使用都可以，其实实质上程序的健壮性和可维护性都太差了，因为在开始做这个功能的时候逻辑设计的太过宽松，没有经过严密的设计，导致后面逻辑中有很多漏洞，而且各个功能之间的逻辑交叉也太多，所以当他要修改一个地方的时候，会非常麻烦，甚至造成他自己都发现不了的新问题，因为他对这种修改会造成什么样的影响都无法预期，所以验收的时候总是有新的问题出现。
经过总结，我觉得功能设计时，逻辑应该非常清楚才行，千万不能模棱两可，而且各个功能之间尽量减小功能之间的耦合度，这会减轻后期的维护负担。
不过，话说回来，我想到另一个问题，最近我在做一个BBS，我发现当我把所有功能做的差不多的时候，我突然觉得我的设计有点缺陷，但是我发现我想修改一些东西的时候，要修改的地方太多，而且要费劲很多心思去找修改哪些地方，但是我们又不可能一开始就能把一个东西设计的完美，当出现这种情况的时候应该怎么办呢？是在原来的设计上修改呢？还是重新设计？如果在原来的设计上修改，显然很痛苦，而且有修改到最后整个系统会崩溃的危险。如果是重新设计，那前面的设计工作岂不是白费，毕竟前面的设计只是有一些地方设计不合理，并不是完全不合理。所以，这种情况该怎么办呢？或许通过一些设计模式可以解决这样的问题，但是我想当问题域复杂到一定程度时，也没有什么设计模式能够说预期到后期扩展和维护的所有情况，因此，所有的软件都是有寿命的。
但是，根据我现在的水平，我解决问题的复杂度都不高，我应该可以通过学习尽量去避免这样的问题，减少后期维护的成本，和扩展的成本。
如果有高人指教，敬请留言。
