敏捷开发对我的帮助
最近被问了一个问题,“在项目中具体是怎么优化代码的”。
让我有了一些思考,我一直认为我是擅长代码优化的,因为我看了许多相关的书籍,在项目中也会积极的代码审查,消除重复代码,我喜欢写出易于修改、可读性良好的代码,因为项目人员总是变动,需求总是变化很快。
书中内容说的都很好,但用到项目中却要经过许多思考。我认为设计模式、敏捷开发等方式都有一个最主要的目的,让项目可以按时上线并且让开发的工作更加轻松。
如果一段代码看起来让自己很难受,那么它必然是可以优化的。
说些具体做法,就如日常生活的整理家务一样,把同样职责的方法封装到一个包下,比如流程类,每个流程都有启动,审核,发送,退回。这样就可以把流程相关的操作都写在一个包下,有新的流程操作就新增一个子类;而不是把流程操作方法都写到具体的业务代码里。
消除重复代码,同样的代码段在一个类里使用第二次就应该抽成私有方法,在第二个类里使用相同的代码就应该抽取到公共类中。
增加注释,许多书中都认为不需要增加注释,但我觉得加点注释还是很有用的,有注释的代码和没注释的代码读起来总感觉是两个难度。
封装shit,把一些长的,难以优化的逻辑给封装起来,至少保证主方法里调用的逻辑很清晰,能看着注释与方法把那段业务讲清楚,我认为这样才有点“源代码即文档”的味道。
在我一开始写代码时,我认为理解清楚需求,在产品给出需求时我能快速的改好代码,就是敏捷。于是在做自建时,我们就尽可能的把代码写的易于修改。
这样做有用,但是不够好,因为不同的现场想看到的东西都不一样,每次提需求都需要定制化改造代码、表结构,想要做一些通用的功能并不容易。我们观察了阿里腾讯这些大厂的做法,他们往往都是卖产品,客户想定制化改造是不存在的……这显然是只有大厂才能走的道路。
后来我觉得只知道写代码行不通,你改的越快,产品变的越快,不能把希望全都寄托于产品足够专业。对业务应当有自己的思考与理解。这样应该也算是依赖倒置原则,越上层的需求就应该越早定好。
于是我们开始尽早地去理解需求,只有理解了需求才能设计好表结构,不会设计出多个id存到一个字段来实现一对多这种事来。理解需求与设计表结构才是应该多花时间的地方,这种时候多偷一分钟懒,开发时可能花一小时也弥补不了。
最后,就是不断地学习新的知识并优化到项目里了,每当学了新的知识,都可以想想用的以前的项目里会不会变得更好。比如我最近重学了下代理模式,就想起之前的多个自建项目,实现类就可以用静态代理来增强实现,而不是用传统的加开关方式实现。
消除重复代码,对需求有自己的理解,不断学习并思考项目中可优化的部分;这就是我认为的敏捷开发,学习敏捷开发思想也确实让我的开发工作变得更简单!