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

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

相关文章

来自专栏web前端教室

NodeJs要凉凉?说nodeJs他爸发布下一代Deno

一直看到有新闻说,node之父又搞了下一代的node,叫Deno。之前一直没当回事,今天得空忍不住打开看了一下。

1365
来自专栏腾讯云数据库(TencentDB)

不知道CynosDB为什么叫真正的云原生数据库?腾讯云数据库的产品欧巴今天跟你聊一聊

注:本文摘自2018年11月22日腾讯云数据库CynosDB新品发布会的演讲实录。随着互联网信息的发展,大家也对云这个词汇也不是特别陌生了,作为全球首选的云服务...

2142
来自专栏Java职业技术分享

程序员怎么利用空闲时间充电提升自己?

初级Java程序员成长为进阶程序员需要不断的积累和辅助,对于新手来说并非遥不可及,只要遵循一定的原则,比如,先养成几个通往成功的好的习惯,程序员怎么利用空闲时间...

1860
来自专栏程序人生

rails, django, phoenix,你们错了

写这个题目估计会招人骂。 这三个著名的 MVC(或者 MTV) framework,分别对应 Ruby,Python,Elixir 三种语言。说他们是这几门语言...

3107
来自专栏WeTest质量开放平台团队的专栏

百万并发量苹果官网准备好了吗?——一分钟学会服务器压力测试

企业需要良好的网站性能。网站的访问速度和顺利的体验是企业必须要做好的事情。本文从苹果官网两年来每次预购都出现的服务器宕机情况,揭示服务器性能测试的重要性,手把手...

1173
来自专栏程序员的SOD蜜

“领域驱动开发”实例之旅(1)--不一样的开发模式      一、分析业务需求。    二、设计领域对象模型    三、测试领域对象模型    四、设计业务处理类    五、设计Entity和Vi

    听说DDD-“领域驱动开发”已经很久了,园子里面已经有不少大牛写过博文介绍,但我一直没有尝试过,直到今年公司的一个项目出现数据库移植,原来的业务逻辑都写...

2377
来自专栏姬小光

如何洞悉隐性需求

俗话说,计划赶不上变化快,无论需求文档做得如何细致,考虑得如何周全,总会有些难以预料的需求变更在每天困扰着我们。开发人员苦恼,产品运营人员更苦恼,毕竟谁也不愿意...

773
来自专栏WeTest质量开放平台团队的专栏

数风流人物之《游龙英雄》--说说如何脱颖而出

在2014年的腾讯游戏嘉年华盛会上,由银汉游戏开发,腾讯游戏独家代理的横板格斗手游大作《游龙英雄》重磅首发,并在之后一发不可收拾,一跃成为一代动作类手游的巅峰之...

993
来自专栏PPV课数据科学社区

干货 : 聚焦于用户行为分析的数据产品。

因为工作需要,我的收藏夹里收集了很多数据相关的产品,其实加入收藏,也一直没有时间好好去研究。这几天恰好有时间翻出来逐个体验了番,顺手贴出来,大家一起研究。 受篇...

4098
来自专栏架构师小秘圈

1亿级PV网站架构演变

作者:叶军 来自:http://www.yejun.cn/?p=1154 一个网站就像一个人,存在一个从小到大的过程。养一个网站和养一个人一样,不同时期需要不...

4527

扫码关注云+社区