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

作者:晓风轻原文: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 条评论
登录 后参与评论

相关文章

来自专栏MixLab科技+设计实验室

技能之H5

自在园O设计Mix科技实验室,正在 搭建Mix技能树,前几期更新的技能有: 技能之AR技术入门 5个用法,关于Gif技能 技能之用iMovie制作预告片 ...

2606
来自专栏java一日一条

10个最佳的网站和App开发工具

这个世界充满了创新,开发的激情和决心是实现更高目标的关键因素。在网站开发中,毫无疑问,工具和可用的在线网页和app设计资源,发挥了重要的作用。

521
来自专栏区块链资讯

使用BCH 操作码的三个新型应用程序

在BCH升级之后的一个多月里,许多开发人员借助重新启用的代码进行了相关应用的开发和完善,比如一些类似memo和blockpress的社交软件可以允许用户以一种连...

1154
来自专栏Crossin的编程教室

个人开发者如何申请微信小程序

作为一个间接性拖延症患者,直到昨天微信小程序疯转之后,我才想起来去做个 demo 试试。 把之前的 python 网页编辑器(公众号最右菜单栏->在线编程)移植...

3366
来自专栏魏艾斯博客www.vpsss.net

DNS 解析和 CDN 加速的区别与联系

1914
来自专栏开源项目

码云周一见 | 7 款不可错过的开源智能硬件架构

近年来,不断有智能硬件产品刷新着我们对于未来生活的期待,从智能手机到智能手表,从智能手环到智能空气净化器,毫无疑问,智能硬件在互联网时代以一种令人惊异的速度飞速...

2354
来自专栏Java社区

这也许是史上最有趣的破解软件合集

1002
来自专栏互联网数据官iCDO

活用GA的监测协议(Measurement Protocol)功能,实现你想不到的数据监测!

大约两年半以前,一位当时就已经从事互联网数据工作多年的前辈在笔者边上如是说:“最没有不可替代性的就是数据分析师,就是个锦上添花的。像什么策划啊、产品啊、美工啊、...

4448
来自专栏互联网高可用架构

从微信支付宝支付接口设计谈 API 接口产品的设计经验和最佳实践【完整版】

3162
来自专栏java一日一条

我的编码习惯 - 如何应对需求变更

我之前的文章 程序员你为什么这么累? 中,我个人观点是加班原因是编码质量占了大部分因素,但是不少同学都不认为是代码质量导致的加班,都认为是不断的需求改动导致的加...

702

扫码关注云+社区