匪兵丁

谁能料到银石赛道上那么大的雨，谁能料到水木现在居然挂了，谁能料到匪兵我这第八篇隔了这么多天，谁能料到项目进行中会会出什么样的岔子。所以说，人在挨踢中，哪有不变更。

无论如何请你记住，不管什么样的变更，只要是你有所准备的，都不可怕。对此有深刻理解的兄弟姐妹，本篇后面的废话你不用看了。

最大，也是最让人头疼的变更一般是来自需求方面的变更。别管用户怎么向你拍胸脯保证，签字画押写血书（汗一个，你们有遇到过的么），那都没用，人家到时候说变就变了，比孙悟空都快。这种变更对项目显然是有伤害的，而我们能做的仅仅是将伤害降到最低。

首先一点，请复习需求篇，尽量去跟踪用户，深入的，细致的，去了解他们的工作流程，尽可能多的预测他们未来可能的变更之处及变更的方向。其次，尽量的将你的系统结构与用户的实际结构保持类似，这样只要用户不变出花来，你也不必重新浇水施肥了，虽然你可能做点剪枝的工作，不过那将轻松的多。这里匪兵我唐僧一下，请重视OO的方法，并且永远不要认为你已经对OO足够了解了。当然了，OO也并不是万能的，现实生活中，依然存在一些实际的东西，它们确实是过程式的，你非要用OO来解释，会把简单的事情搞复杂。第三，尽量和你的客户保持良好的沟通，这里有两层涵义，一是尽早的发现用户可能的变更，一是当有变更时，你可以尽量引导用户向超你有利的方向去引导。最后，请在你的体系结构中留下足够灵活的空间，减少“代码中写死”这种事情，预定义，继承，封装，重载这些概念要用好，尽量让你的系统结构保持低耦合。

技术层面的变更，这是一种非常常见但经常被忽视的变更。主要可能因为这种变更相对比较好处理。首先是因需求变更引起了你的体系结构的变更，这个在前面我们提过，匪兵我的建议是代码之前随便改，代码后期尽量慎重，只要能应付过去，尽量不要大修改，尽管这样会使整个结构变得很难看，但世事难料，我们虽然总是觉得系统是低耦合的，但现实中系统总是在我们忽略的地方保持高耦合。还有一种例如硬件设备的变更，数据库的变更，平台的变更等等。我个人的感觉是这方面的变更如果在写代码之前怎么变都无所谓，写了代码之后救要看运气了，有的时候是整个代码的重写。所以匪兵我的建议同样是慎重而已。

即便如此，这个世界上依然有太多我们无法预料，也很难处理的变更，我没本事提出一套完整的变更管理机制出来，我能给出的建议就是要冷静，越是这种时刻，越不要着急，不要很快的觉得自己已经想清楚了，开个小会就安排人手改，慢一点，多想想总是没坏处的。同时，测试要重新做，包括你认为根本不影响的模块最好也重新做一遍测试，至于测试部门的头打算砍了你，我这里倒是可以向你推销一种匪兵牌钢盔和防弹背心，套装有优惠哦。

广告：下一篇我们讲团队建设，这个是与项目没有直接关系，却能够决定项目成败的重大因素，当猪头小队长的，不可不察啊。