敏捷开发——写代码之三思

老祖宗告诉我们，要三思而后行。我们写代码也要如下三思：

（1）代码是否可以很好的完成功能？

（2）代码是否可以适应变化？

（3）代码是否可以和其他程序员交互？

1代码是否可以很好的完成功能？

毋庸置疑，这是对一个合格程序员的最基本要求。相信绝大部分人都能够完成功能。但代码的质量如何评判？这个没有统一的标准，笔者概括以下几点作为参考标准：

稳定性：版本上线后，是否有致命问题出现？出现问题的数量是否在可接受的范围内？

可扩展性：体现在新增一个需求时，是否可以方便的扩展而又不对原有的功能产生影响？

可维护性：体现在对于原有的需求发生变化时，是否可以方便的改动？

版本稳定性是检验代码可扩展性和可维护性的重要指标，可扩展性和可维护性会在版本的稳定性上体现出来。此外，性能也是一项容易被人忽略的重要指标。不要总是等到用户无法忍受的时候才开始重视性能的问题，这个一定要在平时的应用程序设计、数据库结构设计和写SQL语句的时候重视起来。

2代码是否可以适应变化？

在敏捷开发中，原则上，只要没有提交版本，哪怕是在提交版本的前一天都是容许客户提出需求变化的。若你觉得需求从一开始就应该是一成不变的，那么你得反省一下是否真的理解了什么是敏捷开发。面对客户不断的需求以及需求变更，我们或许会有所抱怨。但冷静下来思考，这就是敏捷，敏捷就是为了快速响应客户需要而生的，所以我们得适应。既然如此，那么我们的代码怎样才能适应变化呢？

敏捷中通常采用迭代增量式开发，一个版本通常分为2到3次迭代，每次迭代2到3周，在做第一个迭代时，我们往往不清楚接下来的变化（除非你是一个很有经验的程序员），此时可以不用考虑变化的问题。若后续迭代中出现了变化，那么彼时就不得不考虑让我们的代码健壮起来。

往往这些变化的地方是客户使用率最高的地方，往往也是提需求最多的地方。

让我们所有功能所对应的代码都能适应变化那是不可能的，也是没必要的，因为常用的功能可能只有20%左右，这意味着有80%左右的功能面临被“冷落”的命运。

结论：等到需求变化或者增量需求时，我们再考虑代码适应变化的能力。

当然，你可以说有经验的程序员可以预见这种变化而提前做了预防。但我很遗憾的告诉你：大量数据表明，再有经验的程序员，绝大部分所谓的“预见”都是没有发生或者根本就是错误的。不过，优秀的程序员，通过提升代码的可扩展性和可维护性来适应不断变化的需求。虽然说等到变化时才考虑适应变化的能力，若是需要变化时，你的代码每次都要做大量的修改，是不是说明你写的代码过于脆弱了？

3代码是否可以和其他程序员交互？

代码是否可以和其他程序员交互简单一点讲就是你的代码可读性如何？

一个人做一个项目的时代已经一去不复返了，往往需要多人协作才能完成。即使细分到各个细小的部件，也会涉及到代码共享的问题。这个时候，代码的可读性就显得尤为重要。

我们往往会抱怨，没有时间考虑代码的可读性问题。这里我们不谈论这些抱怨的原始动机。但本人认为这个不是时间的问题，而是习惯问题。

代码的可读性体现在多个方面，下面列举五点：

（1）注释：包括类注释、方法注释、属性注释、逻辑分支注释等。没用的注释或者错误的注释比没有注释更让人难以忍受，所以我们一定要提高注释的质量；

（2）程序简洁美观，通俗易懂。要争取做到多一行嫌多，少一行嫌少的地步（有空可以多看看优秀类库或者优秀开源框架的源代码）；

（3）命名规范：要注意包命名规范、类命名规范、方法命名规范、属性命名规范等；

（4）代码风格：统一的代码风格；

（5）面向对象而不是面向过程：JAVA是一门面向对象的语言，你写JAVA代码却用面向过程的思维去写，那么对于其他程序员来说无异于是一种折磨。

优秀的代码都是通俗易懂的，若你写的代码只有你自己才能看懂或者很难看懂，那么其他程序员跟你合作就是一种折磨。