不是程序员害怕改需求，而是非程序员不理解程序的灵活性和复杂度的关系，所谓灵活性就是程序代码是否容易修改和扩展，灵活性越高的程序，复杂程度越高，开发量就越大。
所以我们经常遇到这种情况，经理要求做的东西，技术说验证一下，做个Demo，然后咔嚓一顿搞，可能半天就弄出来了，速度很快，但是灵活性很低，仅仅是为了做技术验证。
经理一看这么快，而且功能基本都实现了，那…..
不，这种为了验证技术的Demo，很多时候很难具备良好的扩展性，所以问题来了，这个时候如果新需求提出了，大概率整个Demo要做巨大变动。
如果说项目只是验证阶段，还好，正式开发要重新写，可以旅顺新功能和逻辑，同时提高代码整体灵活性。
但是怕就怕后面的需求超出前期灵活性的预期，导致整个项目，缝缝补补，直到最后没有人能改得动为止，再推倒重写。
有解决的办法没有？有的，就是要花工作量来优化代码架构。
程序员怕改需求，怕的就是要让整个构架做手术的需求，如果你提的需求，不需要对项目大动刀，一般也没人会反感吧。
最后说下有人可能问了，为啥不一开始就照高灵活性去设计代码？主要有两个原因：首先是代码组织构架是比实现功能更有难度的工作，之所以难是因为这玩意除了设计模式可以借鉴别人思路，其他全靠个人经验；
其次是高灵活性带来的高工作量不是线性增长，到了一定程度也没法更灵活了，或者说达到这种程度的灵活性，程序的构架的复杂程度远远超过了业务逻辑，属实本末倒置。
程序员从不怕改需求，程序员怕的是不加钱且不给新加合理工作估时的改需求。
前几天，你拿着图纸告诉我要盖个楼房。
今天，你一拍脑门，突然告诉我，不好意思，图纸拿反了，其实是要挖个地下室。
工期不变，希望赶紧改正。
这哪是改需求，这是虾仁猪心。
因为领导只以结果为导向，无视过程，无视工作量，无视工期。整个研发流程里，最后没有如期上线，pd和pm会把锅甩给开发，上线之后质量不好会把锅甩给测试。基本没见过板子打在pm排期不合理，进度没盯紧，也没见过板子打给pd说他们需求胡乱提，动不动就变更。而且整个研发合作团队，开发测试都是闷头干活不善言辞，说不过他们。所以心里最很痛恨。
转载请注明：落伍老站长 » 神解释：为什么程序员怕改需求？