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

原文出处:晓风轻

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

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

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

看一个宫保鸡丁的段子娱乐一下:这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个系统集成设计成主动被动都可以实现需求)

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

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

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

时间: 2024-10-22 09:32:09

我的编码习惯 - 如何应对需求变更的相关文章

编码规范 -- 如何应对需求变更

如何应对需求变更 现在的程序员为什么这么累,其实很大程度上来说是加班原因使编码质量占了大部分因素,但是不少同学都不认为是代码质量导致的加班,都认为是不断的需求改动导致的加班.但是话又说回来,谁的需求不改动啊?不改动的能叫需求吗? 先看个程序员的段子娱乐一下 客户被绑,蒙眼,惊问:"想干什么?" 对方不语,鞭笞之,客户求饶:"别打,要钱?" 又一鞭,"十万够不?" 又一鞭,"一百万?" 又一鞭.客户崩溃:"你们TMD到

作为产品人,如何更好的应对需求变更?

如何制定一份缜密的项目计划对于产品经理来说可能并不是项目中最难的事情,要应对计划之外的情况,才是最令大家头痛的地方.在项目实际推进过程中,不加控制的需求变更往往给项目带来沉重的负担和无法预料的风险.因此,设计一套合适的需求变更管理流程和规范,对项目和项目经理而言都是不可或缺的. 问题分析 首先对笔者所在项目做一个简单介绍:产品层面,我们是一个C端产品,需求主要来源于运营和策划,就产品阶段而言正处于转型期,现阶段主要以新功能探索为主:项目层面,由于功能较为复杂庞大,可切割空间不大,因此每个版本周期

[转] 项目管理---项目经理如何应对客户的需求变更?

项目管理---项目经理如何应对客户的需求变更? 目录(?)[+] 相信做软件开发的我们,大家都有这样的体会,当我们辛辛苦苦的熬了几个月的通宵.加班后,终于完成了客户提出的V1.0功能需求,当我们大家准备按部就班的进行系统上线时,客户.企业用户突然改变了需求,不想这么做了,提出了新的需求,新的变动,这样对于我们整个团队来说,正如晴天霹雷,很恐怖的事情啊,因为有时候,用户只是简单的一句话,但是对于系统的调整来说工作量是非常大的. 需求变更,本应是客户的权力,但也是实施顾问的为难之处.如果确需变更,当

我的编码习惯 - 配置规范

原文出处:晓风轻 导读:程序员你为什么这么累? 导读(请先仔细阅读):分享我工作中制定配置文件的习惯 工作中少不了要制定各种各样的配置文件,这里和大家分享一下工作中我是如何制定配置文件的,这是个人习惯,结合强大的spring,效果很不错. =============================需求========================== 如我们现在有一个这样的配置需求,顶层是Server,有port和shutdown2个属性,包含一个service集合,service对象有nam

如何控制项目需求变更管理

Trufun UML2建模工具.Trufun Bacon  需求管理工具. Trufun ALM全生命周期产品.Trufun 研发云管理工具等 按照现代项目管理的概念,一个项目的生命周期分为启动.实施.收尾三个过程.需求变更的控制不应该只是项目实施过程考虑的事情,而是要分布在整个项目生命周期的全过程.为了将项目变更的影响降低到最小,就需要采用综合变更控制方法.综合变更控制主要内容有找出影响项目变更的因素.判断项目变更范围是否已经发生等. 进行综合变更控制的主要依据是项目计划.变更请求和提供了项目

需求变更

需求变更是因为需求发生变化.根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更. 需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么.用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备.新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验.随着开发工作的不断进展,系统开始展现功能的雏形

需求变更,产品经理的良心也会痛!

引言:在项目执行过程中,产品经理与后续的合作团队,包括设计.开发.测试等相关人员最尖锐突出的矛盾,就是需求变更,这是产品经理最经常被诟病的地方.频繁的需求变更,对产品.项目进度和团队积极性都有非常大的危害.产品经理一定要不遗余力避免需求变更的情况.本文选自<爆款是怎样炼成的:产品经理晋级宝典>. 作为产品经理,我们一定要理解开发团队及其他团队成员为什么视需求变更为大敌.事实上,需求变更对整个项目都非常有害. 需求有变更,就意味着设计.开发团队的工作有浪费.这首先是资源和时间的浪费. 这会导致团

《小团队项目管理》第三问 --- 如何看待客户的需求变更?

作为一名码农,在项目开发过程中经常会涉及到项目的需求变更,变更的理由也是多种多样,总结而来分为外部和内部,从外部讲,例如:为了顺应某行业新的工作操作规范,甲方要求现有项目在工作流程环节上进行局部功能的变更:从内部讲,通过对市场环境的不间断调研和数据分析,公司产品在同类产品竞争中处于不利地位,市场份额日渐缩小,那么我们的产品设计人员会积极行动起来对产品的整个定位和新业务展开新的思考以寻求更加稳健的创新突破口,这就会对项目产生一定的需求变更. 此图是从CSDN社区截取下的,我相信很多看到这个问题的筒

摆平客户的需求变更之表单扩展属性

客户永远是对的!客户的需求永远是多变的! 需求说明文档写得再详细,说改还得改,程序猿永远这么苦逼. 为了应对客户多变的需求,今天先说说表单的扩展属性.目的是在不修改代码,不重新发布程序的情况下完成表单的扩展. 先下下图: 从这个界面上可以定义如何对表单上进行扩展,在表单上增加一个什么控件,大小.内容.验证都可以的. DEMO地址:http://121.40.148.178:8080/ . 用户名:guest,密码:123456 是的,如果是下拉框的话还能绑定数据源,选择就可以完成,绑定了数据字典