关键词：
如何应对需求变更
现在的程序员为什么这么累，其实很大程度上来说是加班原因使编码质量占了大部分因素，但是不少同学都不认为是代码质量导致的加班，都认为是不断的需求改动导致的加班。但是话又说回来，谁的需求不改动啊？不改动的能叫需求吗？
先看个程序员的段子娱乐一下
客户被绑，蒙眼，惊问：“想干什么?” 对方不语，鞭笞之，客户求饶：“别打，要钱?” 又一鞭，“十万够不?” 又一鞭，“一百万?” 又一鞭。客户崩溃：“你们TMD到底要啥?” “要什么?我帮你做项目，写代码的时候也很想知道你TMD到底想要啥!”
有没有可能存在明确的、不再改动的需求呢？其实很难的。以前很多公司是采用瀑布开发模式，需求阶段时间较长，需要输出完整的需求规范，还要评审几次然后才进入开发，这个时候，需求变更就比较少，但还是有；后来渐渐地公司都赶时髦改成了敏捷开发模式，文档大量简化，于是需求没有考虑清楚就开始开发，需求是边开发边变动。敏捷开发模式间接变成了坑爹的加班开发模式。
关于需求变动，不同的角色定义很不一样。BA觉得这个改动很正常，开发人员觉得就是个需求变更，两边各执一词，这种矛盾长期存在。
下面列举几种场景，大家觉得算不算需求变更？
- 删除对象功能
一开始只能创建者删除，后面变更为管理员也可以删除，再后面变更了某个角色也可以删除。
- 配置功能
一开始使用xml配置，后面修改为json格式，又或者修改为使用数据库配置。
- 导出功能
一开始导出为excel格式，后面变更为导出json格式或者pdf格式。或者一开始导出20个字段，后面变更为导出30个字段。
这些当然都是变更了，但这些真的就是我们加班加点的原因吗？！我们就没有办法只能任人宰割吗？！而我的观点刚好是，正是因为需求变更不可避免，所以我们才更应该把代码写简单，以对付各种各样的需求变化。有以下几点心得建议：
把代码写到最简单
最起码的要求，重要程度不言而喻。改1行简单代码和改10行复杂代码，工作量能一样吗？！测试一个20行的函数和测试一个2行的函数工作量能一样吗？！好比一个房子，你打扫的干干净净收拾得井井有条，将来房子里面的东西搬来搬去都比较简单；但如果你的房子垃圾堆一样，走进去都难（代码无法看），就更加不用说把东西搬动了（改代码）。
把可能变化的封装成函数
请阅读：函数编写建议。很重要的习惯，多思考多抽象和封装，小变更将无法伤害到你。主动思考，主动思考将来可能的各种场景。其实这个不难，你只要有这个意识就成功了一大步。
先做确定的需求
多个功能中先做不会变的功能，一个功能中先做不会变的部分，兵法中叫攻其必救之地。你要知道哪些需求是所有人都明白看上去就很合理的需求，就先开始做，你觉得有争议的需求你可以放后面一点。同样，一个功能中你要知道哪些会变的，哪些是不会变的，不变的先做。
需求实现先后顺序应该难的/确定的先做。先做难的是需要把周期拉长，更多的时间设计；先做确定的是为了避免频繁的改动。
举例：每个系统都有导出功能，我们实现功能之前，先要考虑哪些功能是确定的，哪些功能是很可能变化的？简单分析之后可以知道，从数据库库查询出来然后处理包装数据这是肯定要做的而且不会变的，这个应该先做；而导出为什么格式（xls还是pdf），导出的具体完整字段，字段的格式如何展示这些是会变的，这些你开始甚至都不需要仔细看需求，等要做的时候在确认可能需求都有不同的变化。你完全可以边做前面确定的导出功能边确认其他的细节，确认需求的时间越多，需求就越清晰，变更的概率就越小。
多个功能中，我的习惯是先做最难的功能，最少要开始设计和思考，拉长功能开发周期。有些同学喜欢先做简单的，导致难的问题开发周期不够，后面加班加点也解决不了。加班其实是解决不了太多问题的。
拖延症的一个好处就是，很多需求拖着拖着就不用做了，因为提出人发现了这个需求的不合理。所以先做合理确定的需求。
解耦！解耦！解耦！
个人认为，解耦是编程里面重要的思想，解耦的关键在于：多引入“第三者”，不要直接发生关系。spring的IoC最重要的价值不就是解耦吗？spring的容器不就是“第三者”吗？就像mvc一样，数据和视图要彻底的分离，否则业务代码里面有视图代码改起来是很痛苦的。
在上面的配置规范里面的举例，bean的定义就是第三者，就是为了解耦。如导出功能里面，也要有中介。不要把查询数据，处理数据和导出数据都在一个函数一个循环里面做了。否则导出格式由xls改成pdf的时候，你相当于重写做了一遍功能。jms这些基于消息的都是解耦的思想，架构设计上要多用这些松耦合的设计。
数据结构上要考虑扩展
由于是牵涉到表设计的时候，大家都知道改表结构很痛苦。很多时候，由于时间关系，一开始只做简单的功能，后面会慢慢丰富功能。这虽然不是变更，但是如果你一开始的时候不设计好，很可能后面版本需要大改动，数据库表都要推倒重来，比全新做还痛苦，相信大家会有体会。所以，作为开发组长，做任何一个功能都要想到将来的发展，功能现在可以不做，但必须对将来的变化做到了然于胸。
我举几个例子。
下载功能
工作量问题当前版本只需要显示总下载量。你要考虑将来会不会要列出所有的下载过的用户？如果不需要，可能用一个字段记录总数就可以；如果需要，那么就要用新表，就算现在做起来麻烦一点也不要后面来推翻数据库表设计。
关系表相关功能
牵涉到link的，现在是1对1，要考虑将来有没有可能1对n或者n对n。1对1用个外键就可以了，否则一开始就单独用一张link表。
系统集成
现在只对接一个系统，要考虑将来会不会相同的业务对接多个系统？如果会，你应该直接上jms这种（虽然工作量加大了），不上jms这种的话，也要设计成被动接受的集成方式，那么在增加新系统你都不需要怎么样改。（如果你主动请求的交互方式，多一个系统你就要多一个配置，多测试一遍，如果设计成被动接受的，就不需要什么配置和测试了。而很多时候，2个系统集成设计成主动被动都可以实现需求）
总结
其实，上面说的这些，概括起来，就是要主动思考，多走一步，不要被动接受看到的需求，要对需求的将来变化做好心中有数。当然，你可以说这些变更都是小变，大变怎么办？大变还不给你加工作量，你就走人不干了吧，哪里有这么无良的老板！
每一个开发人员都应该思考：需求变动真的是我加班的最重要原因吗？我的代码是否写得足够好？需求变更里面，我能控制是什么，我不能控制的是什么？我应该做好什么的准备来拥抱需求的变更？
原文参考【https://www.javazhiyin.com/26179.html】
作为产品人，如何更好的应对需求变更？
...预料的风险。因此，设计一套合适的需求变更管理流程和规范，对项目和项目经理而言都是不可或缺的。 问题分析 首先对笔者所在项目做一个简单介绍：产品层面，我们是一个C端产品，需求主要来源于运营和策划，就产品阶段... 查看详情
测试人员遇到不断变化的项目需求该如何应对？
需求频繁变更这个产生的主要原因是： 1.前期需求调研工作没有做到位，在需求调研时没有真正深入了解用户需要什么东西？用户做这个东西的目的是什么？为什么要这么做？ 2.项目经理对项目掌控力度够，在... 查看详情
需求变更管理
...如何对变更如何进行有效的控制。控制好变更必须有一套规范的变更管理过程，在发生变更时遵循规范的变更程序来管理变 查看详情
需求变更，敏捷项目应如何做？
...竟，该面对的还是要面对的。在敏捷项目管理中，我们要如何应对需求变更的问 查看详情
项目经理该如何面对频繁的需求变更?
...求的理解分歧、业务需求改变、项目实现周期长等。二、如何正确应对研发需求变更需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期。为了将项目变更的影响降低到最 查看详情
运维变更难点分析和应对方式
...心配置变更梳理一个可落地的流程，将重大变更尽可能的规范化、自动化，拒绝人工操作需要对变更增加审核 查看详情
你不得不知道的流程规范@多方配合的需求质量控制
...何应对难题，从上游开始质量把控，就需要相对应的流程规范。 经历过一个多方配合的项目-- 查看详情
常见编码规范及其应用(代码片段)
概述对于众多的编码规范一直没有一个清晰的认识，本文旨在理清这些编码规范的定义和特点。ASCIIASCII全称是美国国家信息交换标准码，它是用于字符转换的一个标准，长度是7位，可以标记128个不同的字符，但是这个标准极其... 查看详情
一线技术管理者究竟在管什么事(代码片段)
...质量，来保证整个项目的质量。怎么保证？往下看。制定规范技术评审规范在技术评审前要熟悉产品同学提供的产品文档、业务流程图、交互原型图，反复与产品同学确认，在双方达成一致的情况下，再设计技术方案。设计技术... 查看详情
如何提高工作效率?(代码片段)
...作效率?1规范先行经历了很多公司也面试了很多人,真正把编码规范落地执行好的公司太少,最近去云栖大会听了阿里的讲座,阿里推出的编码文档及工具,也是历经2年多时间才完全把编码规范完善规范起来.目前我们公司也是规范不... 查看详情
如何编写高质量代码(代码片段)
...一低复杂性简练编写高质量代码主要遵循以下几点：代码规范代码规范的好处规范的代码可以促进团队合作规范的代码可以降低维护成本规范的代码有助于代码审查养成代码规范的习惯，有助于程序员自身的成长每个程序员最烦... 查看详情
pycharm如何自动调整python代码符合pep8编码规范(代码片段)
...0c;不管写质量怎样，首先要写的漂亮。Python有一套pep8编码规范标准。什么是pep8编码规范标准PEP是PythonEnhancementProposal的缩写，通常翻译为“Python 查看详情
怎样应对突发性的开发需求
...强的需求控制能力，包括：能迅速识别并整理需求，形成规范、全面、详细的需求文档，对开发团队而言，比较重要的就是：交互原型设计文档，视觉设计相关的材料，算法具体描述等。需求文档能够做到整齐详尽，不遗漏需求... 查看详情
ios进阶-如何制定一套适合自己团队的ios编码规范？(代码片段)
iOS进阶-如何制定一套适合自己团队的iOS编码规范？统一的编码规范，能有限的避免团队成员由于代码风格不一致而导致的相互认同感缺失的问题。好的代码规范，需要从如下八个方面进行约束：常量、变量、属性... 查看详情
ios进阶-如何制定一套适合自己团队的ios编码规范？(代码片段)
iOS进阶-如何制定一套适合自己团队的iOS编码规范？统一的编码规范，能有限的避免团队成员由于代码风格不一致而导致的相互认同感缺失的问题。好的代码规范，需要从如下八个方面进行约束：常量、变量、属性... 查看详情
android开发架构规范(代码片段)
...列前言在开发中，一个良好的开发习惯以及一个开发规范可能会让你少走很多弯路，也会一定程度上的提高代码的可读性，可维护性和可拓展性。当随着需求的不断变更，需要维护项目的时候。当随着项目的代码... 查看详情
行为参数化(代码片段)
...类的实例当做参数加入到方法中。行为参数化可以很好的应对不断变更的需求，使代码更优雅。下面看看示例（来自《Java8实战》） 模拟场景：我们有个客户是苹果大王，他想要一个系统来帮助他快速的把收来的苹果进行分... 查看详情
架构大合集，轻松应对工作需求（中）(代码片段)
前言本文讲述：数据结构和算法，23种设计模式，OKhttp，Retrofit，Glide，Dagger2，MVP，MVC,MVVM,MVI,JetpackRoom,可能字数限制会分为2-3篇讲述😂今天星期一，星期一，星期一😑关注 查看详情