开发人员如何应对频繁更改的需求

做为一个开发人员除了Bug让人头疼外，而一个不靠谱的策划更让人头大。为什么？因为他写的需求文档变来变去，将朝令夕更发挥到了极至。

那么做为开发人员要如何应对这种局面呢？甩袖子不干？这当然可以。但只要你继续做开发就无法保证下 一个需求文档是一层不变的。而要碰到一个不改需求的策划是很难很难的。因为策划面对的是一个个不停变化需求的客户。
那么碰到总是变化的需求要怎么办呢？
首先要仔细的阅读需求文档。真正的了解接下来要实现的具体功能。有不清楚之处一定要向策划人员了解清楚。接下来就着手开发吗？
不！接下来你要好好思考一下，整个需求是否有不合理的地方。由其是业务逻辑有冲突的地方，一定要向策划提出来，并和他们沟通好。
有人说了，策划会犯这种业务逻辑互相冲突的低级错误吗？答案是会的，由其是大项目，需求文档几十甚至上百页的时候，在领导或客户又提了一个新需求时，外加赶时间的情况下，就比较容易出现这种业务逻辑冲突的问题。
当策划再三和你保证需求不会再变时，就可以着手进行开发了，但心中一定要明白策划的保证并不是那么靠谱的，因为人在江湖身不由已呀！强势的客户又提出新需求了，大领导心血来潮对项目作出了最新指示等等。想要拒绝那是需要一定的智慧和勇气的。
即使你遇到了一个智慧和勇气兼有的好策划，跟你说需求不在变了，但这也是靠不住的，因为你会遇到另一只鬼，那就是换策划换人了。
这种事我就遇到过。当时在看他策划时我就觉得一个功能很可能是需要的，再三和策划确认，策划信誓旦旦说肯定不做这个功能。。这位策划人品值很高的，所以接下来的开发过程中那个可能的功能需求自然不在设计考虑范围内了。
结果，在代码以经开发三个多月的时候，策划部工作调整，原来的策划去负责另一个新的项目，调来了一个新的项目策划。他就将那个功能加上了，以经开发三个多月了，我自然不想将这个功能加上，因为如此一来，以前写的代码至少要调整一周的时间才可能将新功能融合进来。开发人员的嘴皮子功夫自然比不上写策划的，最终只能加班加点的改代码了。
所以，在开发中要对可能的需求变更作好预判，并在开发中预留一定的接口来应对可能的需求变更很有必要。当然，预留接口也要把握好尺度，只要这些接口不太费时间，复杂度增加的不多，就能留尽量留，否则将直接影响开发的进度，这样就有些得不偿失了。
客户端在开发过程中将可能变化的地方写的灵活一些，能用配置的用配置，像一些更换频繁的图片，尽量用动态加载，不要直接加到工程中和可执行文件打包到一起。当然最高级的是所有窗口界面都是配置出来的，新加一个功能，只要修改配置文件就可。
服务端的话，一般来说只能预留一些接口，或将一些数据写到配置文件中。但是如果你能把策划需求进行高度抽象概括，并将一切可能的变化都写在配置文件的话，那就不用管策划如何变需求了，因为不论你咋变，我只需改改配置就完活。
改改配置就完成一个新功能，这听起来有些天方夜谭外加不思议，由其一些开发新手会觉得我在忽悠是不是。
这还真不是忽悠大家，客户端改改配置就实现一个新功能，这个我亲眼所见，这边客户刚说完需求，那边花个十几，二十分钟新功能就给你实现了。注意这是实实在在的新功能，不是Demo，客户对新功能不满意？开发人员现场给你分分钟钟搞定。某公司就是凭借这个豪横产品打的国内外同类产品一点脾气都没有的。
可惜的是这么好的一个产品我无法给大家分享，让大家也一起瞧瞧，也证明我没有忽悠大家。毕竟这个客户端的产品我也只是见过而已。
不过，好在服务端写写配置就实现一个功能的，这个是可以和大家分享的。足可以证明我没有忽悠大家。开源服务端的中文名是鼎石数据应用，英文名是dsdbs.下载地址https://gitee.com/dsdbs/dsdbs。
这个开源服务端就是作为访问数据库的一个中间件。接收客户端的访问数据库请求。然后将数据库访问结果返回给客户端。
这里你不但可以配置访问那张表和字段，还能配置socket消息。数据库的接口因为是odbc的，所以支持所有流行的关系数据库。Socket协议目前支持二进制协议和google 的protobuf协议。当然也可以自己扩展支持其它的协议。现在唯一有点美中不足的是没有配置界面。配置起来有点麻烦。
如果在开发中，都能把项目设计的如此灵活，那就可以任他策划任意修改需求了。正所谓任他东南西北风，我自岿然不动。