敏捷开发对我的帮助

　　最近被问了一个问题，“在项目中具体是怎么优化代码的”。

　　让我有了一些思考，我一直认为我是擅长代码优化的，因为我看了许多相关的书籍，在项目中也会积极的代码审查，消除重复代码，我喜欢写出易于修改、可读性良好的代码，因为项目人员总是变动，需求总是变化很快。

　　书中内容说的都很好，但用到项目中却要经过许多思考。我认为设计模式、敏捷开发等方式都有一个最主要的目的，让项目可以按时上线并且让开发的工作更加轻松。

　　如果一段代码看起来让自己很难受，那么它必然是可以优化的。

　　说些具体做法，就如日常生活的整理家务一样，把同样职责的方法封装到一个包下，比如流程类，每个流程都有启动，审核，发送，退回。这样就可以把流程相关的操作都写在一个包下，有新的流程操作就新增一个子类；而不是把流程操作方法都写到具体的业务代码里。

　　消除重复代码，同样的代码段在一个类里使用第二次就应该抽成私有方法，在第二个类里使用相同的代码就应该抽取到公共类中。

　　增加注释，许多书中都认为不需要增加注释，但我觉得加点注释还是很有用的，有注释的代码和没注释的代码读起来总感觉是两个难度。

　　封装shit，把一些长的，难以优化的逻辑给封装起来，至少保证主方法里调用的逻辑很清晰，能看着注释与方法把那段业务讲清楚，我认为这样才有点“源代码即文档”的味道。

　　在我一开始写代码时，我认为理解清楚需求，在产品给出需求时我能快速的改好代码，就是敏捷。于是在做自建时，我们就尽可能的把代码写的易于修改。

　　这样做有用，但是不够好，因为不同的现场想看到的东西都不一样，每次提需求都需要定制化改造代码、表结构，想要做一些通用的功能并不容易。我们观察了阿里腾讯这些大厂的做法，他们往往都是卖产品，客户想定制化改造是不存在的……这显然是只有大厂才能走的道路。

　　后来我觉得只知道写代码行不通，你改的越快，产品变的越快，不能把希望全都寄托于产品足够专业。对业务应当有自己的思考与理解。这样应该也算是依赖倒置原则，越上层的需求就应该越早定好。

　　于是我们开始尽早地去理解需求，只有理解了需求才能设计好表结构，不会设计出多个id存到一个字段来实现一对多这种事来。理解需求与设计表结构才是应该多花时间的地方，这种时候多偷一分钟懒，开发时可能花一小时也弥补不了。

　　最后，就是不断地学习新的知识并优化到项目里了，每当学了新的知识，都可以想想用的以前的项目里会不会变得更好。比如我最近重学了下代理模式，就想起之前的多个自建项目，实现类就可以用静态代理来增强实现，而不是用传统的加开关方式实现。

　　消除重复代码，对需求有自己的理解，不断学习并思考项目中可优化的部分；这就是我认为的敏捷开发，学习敏捷开发思想也确实让我的开发工作变得更简单！