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

前言

开发者的价值体现在技术和产品上。对于App开发，除了实现业务，最重要的是开发的速度、质量和可维护性。速度决定了你能否支持企业抢占市场。质量决定了你能否站稳脚跟不被快速踢出局，可维护性决定了你前进时能否保持轻快的步伐。

速度、质量和可维护性

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

APP开发快：快其实是更容易做，或者更容易知道能不能做。熟悉Android开发的朋友都知道，如果能够在不受干扰的情况下梳理业务逻辑并投入开发，开发速度会非常快，一般规模的App一到两周就可以完成。一个

稳定性：稳定性不如快。我们可以简单地用时间来进行实时的量化评估。稳定与否，要等大量bug出现才知道。其实Android常见的问题无非就是内存、异步、响应等，排查和解决这些问题很容易，难的是如何保证这些问题不发生。

清晰度：清晰度很难达到。牢度可以用时间来量化，稳定性可以用bug统计来量化，但是清晰度却很难量化。代码审查和 scalability 是主观评价，比较落后。很多时候，往往是等到需要实现扩展，甚至是别人接手代码的时候，代码才变得清晰。

对于开发者来说，关于如何快速、稳定、清晰地开发应用程序，这里有一些我的想法。

有限参与商业设计

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

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

另一方面，R&D参与设计也可以指导技术路线，比如是用native App，hybrid App还是ReactNative，用单用户系统还是多用户系统，用什么收费方式.

在实际操作中，你可能会发现收费形式、异常提示，甚至业务逻辑的严谨性等业务设计上的漏洞。

当然，参与设计难免会占用研发时间。有些人会觉得委屈，觉得这是在为产品做自己的工作。如果设计有问题，你修改代码的投入要比修改产品文档的投入多很多。

当然，在公司层面也要有明确的定位。设计方面的研发投入必须是有限的和引导性的。如果大量的研发投入到设计工作中，则是另一种形式的浪费。

异常处理

在实际的开发过程中，BUG清除实际上占据了相当一部分的工作量。有时候一个好的开发计划会因为几个奇怪的bug而耽搁半天。因此，能否尽早处理异常对开发效率有很大的影响。

免责声明：本页文章及图片来源于网络，转载内容仅供传递更多信息和学习之用。转载稿件如涉及版权等问题，请联系管理员处理。