程序员你为什么这么累【续】：如何应对需求变
来源：原创 时间：2017-12-09 浏览：0 次
小编之前的文章 程序员你为什么这么累？ 中，小编个人观念是加班原因是编码质量占了大部分要素，可是不少同学都不认为是代码质量导致的加班，都认为是不断的需求改动导致的加班。这位同学，说的如同他人的需求就不会改变似的！谁的需求不改动啊？不改动的能叫需求吗？哈哈。
先看几个程序员的段子文娱一下
杀一个程序员不需求用枪，改三次需求就能够了。
看一个宫保鸡丁的段子文娱一下：这TM就是规划师不想改图的真实原因！！！
客户被绑，蒙眼，惊问：“想干什么?” 对方不语，鞭挞之，客户求饶：“别打，要钱?” 又一鞭，“十万够不?” 又一鞭，“一百万?” 又一鞭。客户溃散：“你们TMD究竟要啥?” “要什么?我帮你做项目，写代码的时分也很想知道你TMD究竟想要啥!”
有没有可能存在明晰的、不再改动的需求呢？其实很难的。曾经我们公司是瀑布开发形式，需求阶段时刻较长，需求输出完好的需求标准，还要评定几回然后才进入开发，这个时分，需求改变就比较少，但仍是有；后来公司赶时髦改成了灵敏开发形式，文档许多简化，所以需求没有考虑清楚就开端开发，需求是边开发边改变。灵敏开发形式直接变成了加班开发形式。
关于需求改变，不同的人物界说很不一样。BA觉得这个改动很正常，开发人员觉得就是个需求改变，两头各不相谋，这种对立长期存在。
小编罗列几种场景，我们觉得是不是需求改变？
删去目标功用，一开端只能创建者删去，后边改变为管理员也能够删去，再后边改变了某个人物也能够删去。
装备功用，一开端运用xml装备，后边修改为运用数据库装备。
导出功用，一开端导出为excel格局，后边改变为导出json格局或许pdf格局。或许一开端导出20个字段，后边改变为导出30个字段。
这些当然都是改变了，但这些真的就是我们加班加点的原因吗？！我们就没有办法只能任人宰割吗？！而我的观念刚好是，正是因为需求改变不可避免，所以我们才更应该把代码写简略，以抵挡各式各样的需求改变。有以下几点心得主张：
1 把代码写到最简略
最起码的要求，我之前一系列的文章说的就是这个。重要程度不需求再讲了。改1行简略代码和改10行杂乱代码，作业量能一样吗？！测验一个20行的函数和测验一个2行的函数作业量能一样吗？！
比如一个房子，你清扫的干干净净收拾得有条不紊，将来房子里边的东西搬来搬去都比较简略；但如果你的房子垃圾堆一样，走进去都难（代码无法看），就愈加不用说把东西搬动了（改代码）。
2 把可能改变的封装成函数
请阅览：函数编写主张。很重要的习气，多考虑多笼统和封装，小改变将无法损伤到你。自动考虑，自动考虑将来可能的各种场景。其实这个不难，你只需有这个认识就成功了一大步！
3 多个功用中先做不会变的功用，一个功用中先做不会变的部分
兵书中叫攻其必救之地。你要知道哪些需求是一切人都理解看上去就很合理的需求，就先开端做，你觉得有争议的需求你能够放后边一点。相同，一个功用中你要知道哪些会变的，哪些是不会变的，不变的先做。
举例：每个体系都有导出功用，导出功用里边，从数据库库查询出来然后处理包装数据这是必定要做的并且不会变的，这个应该先做；而导出为什么格局（xls仍是pdf），导出的详细完好字段，字段的格局怎么展现这些是会变的，这些你开端甚至都不需求仔细看需求，等要做的时分在承认可能需求都有不同的改变。你完全能够边做前面断定的导出功用边承认其他的细节，承认需求的时刻越多，需求就越明晰，改变的概率就越小。
多个功用中，我的习气是先做最难的功用，最少要开端规划和考虑，拉长功用开发周期。有些同学喜爱先做简略的，导致难的问题开发周期不行，后边加班加点也解决不了。加班其实是解决不了太多问题的。
延迟症的一个优点就是，许多需求拖着拖着就不用做了，因为提出人发现了这个需求的不合理。所以先做合理断定的需求。
4 规划上多采纳解耦的规划，多引进“第三者”，不要直接发生联系
个人认为，解耦是编程里边重要的思维。spring的ioc最重要的价值不就是解耦吗？就像mvc一样，数据和视图要完全的别离，不然事务代码里边有视图代码改起来是很苦楚的。
我的编码习气 - 装备标准里边的举例，bean的界说就是第三者，就是为了解耦。如导出功用里边，也要有中介。不要把查询数据，处理数据和导出数据都在一个函数一个循环里边做了。不然导出格局由xls改成pdf的时分，你相当于重写做了一遍功用。jms这些根据音讯的都是解耦的思维，架构规划上要多用这些松耦合的规划。
5 数据结构上要考虑功用将来的扩展
许多时分，因为时刻联系，一开端只做简略的功用，后边会渐渐丰厚功用。这尽管不是改变，可是如果你一开端的时分不规划好，很可能后边版别需求大改动，数据库表都要推倒重来，比全新做还苦楚，信任我们会有领会。所以，作为开发组长，做任何一个功用都要想到将来的开展，我举几个比如。
下载功用，作业量问题当时版别只需求显现总下载量。你要考虑将来会不会要列出一切的下载过的用户？如果不需求，可能用一个字段记载总数就能够；如果需求，那么就要用新表，就算现在做起来费事一点也不要后边来推翻数据库表规划。
牵涉到link的，现在是1对1，要考虑将来有没有可能1对n或许n对n。1对1用个外键就能够了，不然一开端就单独用一张link表。
体系集成的，现在只对口一个体系，要考虑将来会不会相同的事务对接多个体系？如果会，你应该直接上jms这种（尽管作业量加大了），不上jms这种的话，也要规划成被迫承受的集成方法，那么在添加新体系你都不需求怎么样改。（如果你自动恳求的交互方法，多一个体系你就要多一个装备，多测验一遍，如果规划成被迫承受的，就不需求什么装备和测验了。而许多时分，2个体系集成规划成自动被迫都能够实现需求）
其实，我上面说的这些，归纳起来，就是要自动考虑，多走一步，不要被迫承受看到的需求，要对需求的将来改变做好心中有数。当然，你能够说这些改变都是小变，大变怎么办？大变还不给你加作业量，你就走人不干了吧，哪里有这么无良的老板！
