前言

开发者的价值，是通过技术和产品体现的，对于App开发来说，除了实现业务之外，最重要的莫过于开发的速度、质量和可维护性，速度决定你能否支撑公司抢占市场，质量决定你们能不能站稳位置不被迅速踢走，可维护性决定你们继续前行时能否保持轻快的步伐。

速度、质量和可维护性

对速度、质量和可维护性的要求，其实就是又快，又稳，又清晰的要求。

快：快其实是最容易做到，或者说最容易知道能不能做到的事情，熟悉的Android开发的朋友都知道，如果能理清业务逻辑，不受干扰地投入开发，开发速度可以很快，一般普通规模的App，一到两周就能完成。

稳：稳不像快，可以简单地用时间进行即时的量化评价，我们要等大量bug出现之后，才知道稳不稳，可是一般赶工速度一快起来，就很容易出现大量bug。其实Android常见问题无非是内存、异步、响应等，要排除和解决这些问题很容易，难的是怎样确保不出现这些问题。

清晰：清晰是最难做到的，快可以通过时间量化，稳可以通过bug统计量化，但是清晰是很难量化的，代码审查和可扩展性都是主观评价，而且相当滞后，很多情况下，往往要等到需要实现扩展，甚至换人接手代码时，才知道代码不清晰。

对于开发者来说，怎样才能又快又稳又清晰地开发App，这里梳理了我的几点心得。

有限参与业务设计

从职责分工上，业务设计是运营部门和产品经理的工作，确实不应由研发负责，但我说的是参与，研发（包括测试）应当尽早参与业务设计，一方面提前发现问题，另一方面可以引导和建议技术路线。

研发参与设计，可以规避很多问题，例如通信压力、加载速度、延迟时间、硬件负载等移动开发特有问题，不能指望运营和产品能像专业的研发一样面面俱到，考虑周翔。

另一方面，研发参与设计还可以引导技术路线，例如采用原生App、混合App还是ReactNative形式，采用单用户体系还是多用户体系，采用什么收费形式等。

在实际操作中，业务设计诸如收费形式，异常提示，乃至于业务逻辑上的严密性，你都可能发现漏洞。

当然，参与设计必然会占用研发时间，有人会觉得委屈，感觉这是替产品做了他们的工作，但其实研发参与设计，省下的还是自己的时间，因为无论产品如何设计，最终都需要技术来研发实现，如果设计上出了问题，你修改代码的投入，可比产品改文档的那点儿投入大多了。

当然，公司层面也应有清楚的定位，研发对设计的投入，必须是有限的指导性的，如果大量把研发投入到设计工作，就是另一种形式的浪费了。

异常处理

在实际开发过程中，除bug其实占了相当一部分工作量，有时候好好的开发计划，因为几个诡异的bug就得耽误半天，所谓“码字5分钟，排错两小时”是也。所以，能否尽早尽快处理异常，是非常影响开发效率的。

处理异常，云掌门有这么几条心得：

提前考虑异常处理，在写正常流程的业务代码之前，先考虑异常，“未虑胜，先虑败”，沿着业务流程分支，先把异常情况都处理掉，例如获取在线数据显示一个列表，先考虑网络异常、服务器报错、数据失败等异常情况，并依次给出相应提示，最后才处理数据正常的情况，本来就要写正常业务代码和异常处理代码，只需要调换一下工作的先后顺序，其实你投入的开发时间没有增加，但是你的效率却大大提升了，因为一旦出现异常，我们可以迅速判断异常原因，节省大量时间。

云掌门已经为200多个创业项目开发了基于移动端的技术平台，多数项目均已投入运营。截至目前，月流水额超过1000万的项目有12个，获得各种融资的项目至少有18个，各项目累计用户数超过4000万。云掌门倾力打造简约极致的用户体验，创造有吸引力、生命力、影响力和价值度的产品。