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

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

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

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

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

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

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

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

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

  1. 删除对象功能,一开始只能创建者删除,后面变更为管理员也可以删除,再后面变更了某个角色也可以删除。
  2. 配置功能,一开始使用xml配置,后面修改为使用数据库配置。
  3. 导出功能,一开始导出为excel格式,后面变更为导出json格式或者pdf格式。或者一开始导出20个字段,后面变更为导出30个字段。

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

1 把代码写到最简单

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

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

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

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

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

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

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

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

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

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

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

我的编码习惯 - 配置规范里面的举例,bean的定义就是第三者,就是为了解耦。如导出功能里面,也要有中介。不要把查询数据,处理数据和导出数据都在一个函数一个循环里面做了。否则导出格式由xls改成pdf的时候,你相当于重写做了一遍功能。jms这些基于消息的都是解耦的思想,架构设计上要多用这些松耦合的设计。

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

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

  1. 下载功能,工作量问题当前版本只需要显示总下载量。你要考虑将来会不会要列出所有的下载过的用户?如果不需要,可能用一个字段记录总数就可以;如果需要,那么就要用新表,就算现在做起来麻烦一点也不要后面来推翻数据库表设计。
  2. 牵涉到link的,现在是1对1,要考虑将来有没有可能1对n或者n对n。1对1用个外键就可以了,否则一开始就单独用一张link表。
  3. 系统集成的,现在只对口一个系统,要考虑将来会不会相同的业务对接多个系统?如果会,你应该直接上jms这种(虽然工作量加大了),不上jms这种的话,也要设计成被动接受的集成方式,那么在增加新系统你都不需要怎么样改。(如果你主动请求的交互方式,多一个系统你就要多一个配置,多测试一遍,如果设计成被动接受的,就不需要什么配置和测试了。而很多时候,2个系统集成设计成主动被动都可以实现需求)

=========================================

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

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

图片来自网络,侵删。

原文发布于微信公众号 - java一日一条(mjx_java)

原文发表时间:2017-12-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏阮一峰的网络日志

Android,开源还是封闭?

满大街都在谈论Android。 它是当红炸子鸡。许多人觉得,iPhone将受到它的强力挑战。 ? 我也曾经对它充满了期待,但是后来的事态发展,令我改变了看法。前...

3557
来自专栏知晓程序

除了「星标」小程序,微信「跳票已久」的新能力也上线了!

昨晚,许久「没搞事」的微信团队,发布了一个颇为「可爱的」新能力——小程序星标功能。

551
来自专栏杨建荣的学习笔记

从问题的处理方式感悟学习方法 (r4笔记第39天)

有时候当你碰到一些问题一筹莫展的时候,如果能够看到某个帖子的问题和你碰到的刚好一致,那种欣喜的感觉真是难以形容。 但是有些问题尽管发生的错误一致,处理的方式却不...

3035
来自专栏云计算D1net

你为什么需要在云端构建Linux服务器?

云端Linux服务器比以往来得成本更低、性能更好。 要是你之前还没有启动过云端Linux服务器,眼下也许正是大好时机。原因何在因为你在短短几分钟内就能安装好一台...

5877
来自专栏人人都是极客

计算机的基本组成

严格来讲计算机从诞生到现在经历了很多阶段,已经发展成为一种自动地、高速地、精确地进行信息处理的电子设备,也是20世纪的重大发明之一。

1302
来自专栏福利活动清单

腾讯云学生优惠

腾讯云学生优惠相对于阿里云的槽点在于价格贵了6元一年,而且只能学生认证才能够购买。但是!但是腾讯云学生机可以选择搭配学生优惠的云数据库体验套餐,最低3元一月,还...

19.4K14
来自专栏数据和云

招商银行王龙:金融科技银行数据架构设计的13条守则(含PPT)

作者简介:王龙,招商银行数据中心MySQL资深架构师,将MySQL引入招商银行,并从无到有建设MySQL生态,解决了MySQL在银行领域使用的诸多问题。

1855
来自专栏Albert陈凯

2018-08-06 数据权限管理权限管理的目标是什么?安全与便利的矛盾,有解么?总结常见开源方案基于开发平台服务入口的权限管控思路

https://blog.csdn.net/colorant/article/details/78672404

2822
来自专栏非著名程序员

是的,这是我的记录之道

前几天分享了两篇关于我的学习之道,面试之道的文章。颇受大家的好评,很多人都感觉受益良多,给了他们借鉴学习的经验。对此,其实我心里还是非常欣慰的,今天继续分享关于...

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

5招教你轻松获得手机App好评

引言:在应用程序方面,意见和评论也会影响到应用程序商店搜索结果的可见性,以及它们在app store中出现的概率。因此,如何能获得更多的好评呢?本文教你5招。 ...

3835

扫码关注云+社区

领取腾讯云代金券