程序员你为什么这么累续:如何应对需求变更

作者:晓风轻原文:https://zhuanlan.zhihu.com/p/28719726

我之前的文章程序员你为什么这么累?中,我个人观点是加班原因是编码质量占了大部分因素,但是不少同学都不认为是代码质量导致的加班,都认为是不断的需求改动导致的加班。这位同学,说的好像别人的需求就不会变动似的!谁的需求不改动啊?不改动的能叫需求吗?哈哈。

先看几个程序员的段子娱乐一下

杀一个程序员不需要用枪,改三次需求就可以了。

看一个宫保鸡丁的段子娱乐一下:这TM就是设计师不想改图的真正原因!!!

客户被绑,蒙眼,惊问:“想干什么?”对方不语,鞭笞之,客户求饶:“别打,要钱?”又一鞭,“十万够不?”又一鞭,“一百万?”又一鞭。客户崩溃:“你们TMD到底要啥?”“要什么?我帮你做项目,写代码的时候也很想知道你TMD到底想要啥!”

有没有可能存在明确的、不再改动的需求呢?其实很难的。以前我们公司是瀑布开发模式,需求阶段时间较长,需要输出完整的需求规范,还要评审几次然后才进入开发,这个时候,需求变更就比较少,但还是有;后来公司赶时髦改成了敏捷开发模式,文档大量简化,于是需求没有考虑清楚就开始开发,需求是边开发边变动。敏捷开发模式间接变成了加班开发模式。

关于需求变动,不同的角色定义很不一样。BA觉得这个改动很正常,开发人员觉得就是个需求变更,两边各执一词,这种矛盾长期存在。

我列举几种场景,大家觉得算不算需求变更?

删除对象功能,一开始只能创建者删除,后面变更为管理员也可以删除,再后面变更了某个角色也可以删除。

配置功能,一开始使用xml配置,后面修改为使用数据库配置。

导出功能,一开始导出为excel格式,后面变更为导出json格式或者pdf格式。或者一开始导出20个字段,后面变更为导出30个字段。

这些当然都是变更了,但这些真的就是我们加班加点的原因吗?!我们就没有办法只能任人宰割吗?!而我的观点刚好是,正是因为需求变更不可避免,所以我们才更应该把代码写简单,以对付各种各样的需求变化。有以下几点心得建议:

1 把代码写到最简单

最起码的要求,我之前一系列的文章说的就是这个。重要程度不需要再讲了。改1行简单代码和改10行复杂代码,工作量能一样吗?!测试一个20行的函数和测试一个2行的函数工作量能一样吗?!

好比一个房子,你打扫的干干净净收拾得井井有条,将来房子里面的东西搬来搬去都比较简单;但如果你的房子垃圾堆一样,走进去都难(代码无法看),就更加不用说把东西搬动了(改代码)。

2 把可能变化的封装成函数

请阅读:函数编写建议。很重要的习惯,多思考多抽象和封装,小变更将无法伤害到你。主动思考,主动思考将来可能的各种场景。其实这个不难,你只要有这个意识就成功了一大步!

3 多个功能中先做不会变的功能,一个功能中先做不会变的部分

兵法中叫攻其必救之地。你要知道哪些需求是所有人都明白看上去就很合理的需求,就先开始做,你觉得有争议的需求你可以放后面一点。同样,一个功能中你要知道哪些会变的,哪些是不会变的,不变的先做。

举例:每个系统都有导出功能,导出功能里面,从数据库库查询出来然后处理包装数据这是肯定要做的而且不会变的,这个应该先做;而导出为什么格式(xls还是pdf),导出的具体完整字段,字段的格式如何展示这些是会变的,这些你开始甚至都不需要仔细看需求,等要做的时候在确认可能需求都有不同的变化。你完全可以边做前面确定的导出功能边确认其他的细节,确认需求的时间越多,需求就越清晰,变更的概率就越小。

多个功能中,我的习惯是先做最难的功能,最少要开始设计和思考,拉长功能开发周期。有些同学喜欢先做简单的,导致难的问题开发周期不够,后面加班加点也解决不了。加班其实是解决不了太多问题的。

拖延症的一个好处就是,很多需求拖着拖着就不用做了,因为提出人发现了这个需求的不合理。所以先做合理确定的需求。

4 设计上多采取解耦的设计,多引入“第三者”,不要直接发生关系

个人认为,解耦是编程里面重要的思想。spring的ioc最重要的价值不就是解耦吗?就像mvc一样,数据和视图要彻底的分离,否则业务代码里面有视图代码改起来是很痛苦的。

5 数据结构上要考虑功能将来的扩展

很多时候,由于时间关系,一开始只做简单的功能,后面会慢慢丰富功能。这虽然不是变更,但是如果你一开始的时候不设计好,很可能后面版本需要大改动,数据库表都要推倒重来,比全新做还痛苦,相信大家会有体会。所以,作为开发组长,做任何一个功能都要想到将来的发展,我举几个例子。

下载功能,工作量问题当前版本只需要显示总下载量。你要考虑将来会不会要列出所有的下载过的用户?如果不需要,可能用一个字段记录总数就可以;如果需要,那么就要用新表,就算现在做起来麻烦一点也不要后面来推翻数据库表设计。

牵涉到link的,现在是1对1,要考虑将来有没有可能1对n或者n对n。1对1用个外键就可以了,否则一开始就单独用一张link表。

系统集成的,现在只对口一个系统,要考虑将来会不会相同的业务对接多个系统?如果会,你应该直接上jms这种(虽然工作量加大了),不上jms这种的话,也要设计成被动接受的集成方式,那么在增加新系统你都不需要怎么样改。(如果你主动请求的交互方式,多一个系统你就要多一个配置,多测试一遍,如果设计成被动接受的,就不需要什么配置和测试了。而很多时候,2个系统集成设计成主动被动都可以实现需求)

其实,我上面说的这些,概括起来,就是要主动思考,多走一步,不要被动接受看到的需求,要对需求的将来变化做好心中有数。当然,你可以说这些变更都是小变,大变怎么办?大变还不给你加工作量,你就走人不干了吧,哪里有这么无良的老板!

希望每一个开发人员都认真思考,需求变动真的是我加班的最重要原因吗?我的代码是否写得足够好?需求变更里面,我能控制是啥,我不能控制的是啥?我应该做好什么的准备来拥抱需求的变更?愿天下有永恒不变的需求~~

系列文章阅读

本文来自企鹅号 - java一日一条媒体

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏开源优测

从0到1:测试工程师应该具备的基本功底

今天就测试基础知识进行分享,从几个层面来分享软件测试从业者应该具备什么样的基本功底。 笔者针对测试从业者必须掌握的基本功做了个分层: 1、操作系统层 在这个层面...

3308
来自专栏开源优测

从0到1:测试工程师应该具备的基本功底

今天就测试基础知识进行分享,从几个层面来分享软件测试从业者应该具备什么样的基本功底。 笔者针对测试从业者必须掌握的基本功做了个分层: 1、操作系统层 在这个层面...

27910
来自专栏互联网杂技

开始学习Linux的一些建议

建议读者范围 1、有开发经验者。 2、科研人员(由其Numrical)。 3、动手能力强的。 4、只是好奇,对于Linux只是浅尝辄止的就不建议继续往下看了。 ...

5497
来自专栏Rainbond开源「容器云平台」

Lagom:一个新的微服务框架

1543
来自专栏携程技术中心

干货 | 携程高可用架构的演变和迭代——应用开发者视角

作者简介 周源,携程技术中心基础业务研发部高级研发经理,从事软件开发10余年。2012年加入携程,先后参与支付、营销、客服、用户中心的设计和研发。 前言 携程的...

2605
来自专栏java一日一条

2014年最流行的应用服务器

距离2013年应用服务器市场份额回顾已经有超过一年的时间了。为了调查14个月来的变化,我们收集了2013年2月到2014年5月间启用了On Demand Plu...

551
来自专栏北京马哥教育

大神分享美团外卖订单中心演进之路

? 作者:何轼 来源: http://tech.meituan.com/mt_waimai_order_evolution.html 前言 美团外卖从20...

3377
来自专栏喔家ArchiSelf

面向IoT的协议选择思考

对于使用传感器和保持连接性的IoT系统而言,如何使用这些元素和多种互联网技术相结合呢?

1286
来自专栏大宽宽的碎碎念

系统的请求量突然增大数倍怎么办?面试中怎么回答真实世界的流量问题最后的话

45016
来自专栏BestSDK

如果你的APP没有这些漏洞,就说明成功了

用户卸载你的app的原因有时候很简单,也许是你的app经常突然崩溃,或者是app界面设计得不够直观,或者是用户需要填写的个人资料过多。 这是用户体验冲突的3个例...

2544

扫码关注云+社区