让Android项目健壮的几个建议

    近期一直思考，如何提高自身代码水平，如何去沉淀开发经验。至今接到需求考虑不是如何做，而是如何做好，对代码质量要求也越来越高。 如何用优雅的手法，去做一件漂亮的事情，用最简洁且可靠的写法完成一个功能点。一直希望自身所写的代码能够清晰，能够一眼看下去不啰嗦。随着业务需求的变化，代码也越来越复杂。如果没有灵活分层架构，估计这份代码很快会令你崩溃的。何为代码健壮，在很多设计模式相关的书中也有提及。简单理解健壮含义：命名清晰易懂，逻辑层次分明，输出是百分百正确的。如何衡量代码健壮的，自身理解：让调用者完全不操心去用你的模块引起各种问题。

     在实际工作中的Android项目、开源类库。仔细观察会发现，优秀项目（开源类库）往往都是一眼看过去就是层次清晰，功能命名相当规范。到细节处观察某个类、方法、变量看其命名就知道作用。类与类之间保持高内聚，低耦合。所以优秀项目必然能体现上述共同点，所谓优秀当然不止是代码优雅，高效，它也必须是健壮的。如何在Android代码拥有更健壮的代码，也基于这个需求点写一些自己的心得，下面有几点建议：

建议1－架构:

    大型项目参与开发人数较多时，须选一套易于扩展、维护的架构。在项目开始时就要选定，才有利于后期迭代版本。推荐使用MVX系列(MVC,MVP,MVVM)，具体使用在此就不详细展开，建议google相关文章预研下。熟知思想后，设计时大家没必要用死脑筋去按照某些套路去搞，关键是吸收其优秀的思想，具体如何分层还是取决于项目自身。划分架构会导致整个项目前期进度缓慢，但后续版本迭代、维护工作绝对是高效率，所以这点开发成本绝对是不亏的。这样也为写出健壮的代码，提供一个良好的平台。

建议2－设计模式:

   在实现项目过程中，设计模式是很重要的，解决一个需求问题的写法有千种万种，我们要Get到大牛们设计精华。使用设计模式要在适合的场合用适合的设计方案来解决一个问题，当然这里提得比较抽象，主要是想提醒大家不要去滥用设计模式，滥用只能适得其反。设计模式比较实用的有观察者模式，单例模式(如果不注意某些操作，容易导致内存泄漏)，状态模式，工厂模式等，上述是我在设计时运用最多的。这里建议遇到问题也不妨尝试用适合设计模式去解决，可以使代码更优雅，更健壮。

建议3－功能划分:

    功能划分是一件必须做的事情，如功能没有划分，那样设计的实现不敢想象。在正式项目当中，要设计一个本地数据库读写，相信大家第一件事情就是将代码抽离出来，然后提供一个入口让外界调用，其实这就是功能划分。在这里也是建议大家要有一个良好的划分习惯。首先从包划分，包中定义是该功能一个容器，然后划分接口、实现类。层次一定要鲜明，这也是保证代码更健壮的前提。

建议4－命名规范:

     命名规范是开发过程当中最重要一环，这里我建议命名一定要符合团队内使用规范并要求见名知意。往往团队合作之间会涉及到你动我的代码，我碰你的代码。如果命名不能见名知意即使有再多注释，代码可读性也是极差的。这个前提不做好，更不能高谈代码健壮了。命名规范中所包含：功能分层、资源、接口、类、方法、变量、常量。

建议5－接口:

   基于接口编程是良好的习惯，定义接口有利于解耦合。接口定义从代码角度来看就是隔离了具体实现，调用者不需要关心具体的实现细节。接口定义需要用心去分析，把一个功能点抽象出来。在接口定义期间必须保证一个原则：尽可能暴露必要接口方法。这里顺便提一点，就是接口通常在常替换或潜在替换地方进行定义。举个例子：定义一个接口实现一个播放器，这个播放器使用MediaPlayer来处理，后续需求中出现需支持MediaPlayer处理不了的特殊格式文件，这个时候就要独立写一个既支持原来格式也要支持新格式解码的播放器，我们只要实现定义接口替换原来MediaPlayer处理就可以简单地实现这个需求，无需做较大的改动。

建议6－类:

   无论是基于接口编写实现类，还是编写所需的工具类，视图类，业务逻辑控制类等。从开发过程遇到最多就是实现一个类时，因工作进度比较紧迫而考虑不周全。当然很多情况下导致最后还是选择重构，从而达不到高效，敏捷的效果。经验告诉我们在设计一个类时，对外界来说只暴露需要的方法把细节隐藏，对内部尽量定义少的成员变量，如果成员变量过多时可以考虑抽象成一个实体类。在设计方法时能使用局部变量的尽量使用，不建议使用成员变量。

建议7-代码审查

   在代码质量把控重要的一环就是代码审查，代码审查的过程是当你设计好需求逻辑后，在提交到SVN前做的一件事情。就是将代码提交代码，先提交至CodeReview服务器通过邀请评审委员进行代码审查，通过后才能进行SVN提交。其实做这一步很有必要，让团队人员可以阅读自己的代码，发现自身发现不了的问题。当然也要认真思考评审者提出的疑问，看看评审者是否存在看漏或看错问题。虽然这个过程会影响到正常开发进度，但是从整个项目迭代阶段，可保证成本最低质量最高。

建议8-重构

   在设计具体实现逻辑时，要学会纠结代码。对不满足的设计要去不断优化改进，只有更优没有最优。最常做的就是方法名、变量名的重构工作，像方法过于庞大的时候重构为几个小逻辑方法组合解决一个问题。只有不断通过重构不完美的代码，代码才能变得越来越健壮。

上述几条建议是自身对Android开发一些感悟，希望大家多多指教，相互学习。