开发人员的价值是通过技术和产品来表达的。 对于App开发来说，最重要的是开发的速度，质量和可维护性.. 速度决定你是否能支持公司抢占市场，质量决定你是否能站稳脚跟，而不是很快被踢，可维护性决定你是否能在前进的过程中保持轻快的步伐..
速度、质量和可维护性
速度，质量和可维护性的要求，事实上，快速，稳定，明确的要求。
快：快其实是最容易能够做到，或者说最容易知道自己能不能做到的事情，熟悉的Android开发的朋友都知道，如果能理清企业业务发展逻辑，不受干扰地投入资源开发，开发工作速度分析可以提高很快，一般都是普通用户规模的App，一到两周就能完成。
稳定性：稳定性没有那么快，可以简单的利用时间进行即时定量评估，我们要等大量bug出现后再稳定，但是一般都是冲速度加快，很容易出现大量bug.其实Android最常见的问题就是内存，异步，响应等.. 这些问题很容易消除和解决，很难确保不发生。
清除：清除是最难实现的，按时间Quantify的快速，稳定的缺陷可以通过统计数据进行量化，但它显然是难以量化，代码审查和可扩展性都是主观的评价，但相对滞后，在很多情况下，往往有等到需要实现扩张，即使换人接手代码，知道代码是不明确的。
对于企业开发者一般来说，怎样发展才能又快又稳又清晰地开发App，这里梳理了我的几点学习心得。
有限参与业务设计
从职责分工来看，业务设计是运营部和产品经理的工作，确实研发不负责任，但我说参与，研发（包括测试）要尽早参与业务设计，一方面提前发现问题，另一方面可以指导和建议技术路线..
R＆d设计，可以避免很多问题，如通信压力，加载速度，等待时间和其他移动硬件负载具体的发展问题，而且产品不能指望像一个专业的R＆d操作，像一切，考虑周翔。
另一重要方面，研发人员参与教学设计还可以通过引导企业技术发展路线，例如我们采用原生App、混合App还是ReactNative形式，采用单用户体系建设还是多用户体系，采用什么收费形式等。
在实践中，您可能会发现业务设计中的漏洞，如收费形式、异常提示，甚至业务逻辑严谨。
当然，参与设计必然要占用开发时间，有些人会觉得很委屈，我觉得这是为做好本职工作的产品，但在设计事实的研究和开发，或节省时间，因为不管产品设计，技术将最终需要研究和开发来实现的，如果设计出了问题，你改变输入代码到的东西，主要是改变文档产品相媲美。
当然，公司企业层面也应有一个清楚的定位，研发对设计的投入，必须是有限的指导性的，如果需要大量把研发资金投入到设计研究工作，就是通过另一种表现形式的浪费了。
异常处理
在实际的开发过程中，除了bug其实占了相当一部分的工作量，有时候很好的开发计划，因为几个奇怪的bug都要延迟半天，所谓的“码字5分钟，两小时错”也是。 因此，能尽快处理异常，是非常影响开发效率的..
处理异常，所以我有一些想法：
提前进行考虑异常信息处理，在写正常生产流程的业务代码之前，先考虑异常，“未虑胜，先虑败”，沿着业务管理流程分支，先把异常变化情况都处理掉，例如学生获取在线分析数据结果显示出了一个列表，先考虑通过网络发展异常、服务器报错、数据失败等异常情况，并依次给出相应提示，最后才处理相关数据能够正常的情况，你本来就要写正常经营业务代码和异常处理代码，你只需要调换一下社会工作的先后顺序，其实你投入的开发利用时间就是没有明显增加，但是你的效率却大大提升了，因为他们一旦出现异常，我们教师可以得到迅速判断异常重要原因，节省大量时间。
在你进入复杂的商业逻辑之前，处理相对简单的异常分支也有好处，这可以防止你被商业逻辑暴露在大脑缺氧中，然后回到处理异常分支的情况下，在一个或写出的情况下。
之前和数据接口之后隔离对接站时，最好不要直接使用，一方面由背景，中间层映射所提供的数据，如果背景数据是一个问题（异常数据，变化区域等），你将能够找到当映射数据和定位问题;而另一方面，也有利于在App的形式更适合于数据持久化数据的使用。
另外，建议做一个接口进行录入与检查管理工具，形式不论，但要能轻松地维护前后台数据接口，最好能自动分析检测技术接口反馈学生是否能够正常（服务器负载过大、字段变更、第三方物流服务过期等）。
异常信息的收集、汇总和数据持久化
如果发生异常，代码的最重要的线获取异常（例如MainActivity，线61）和异常的原因（如一个零指示字例外），并记录为本地和查看文件上传和
不要过度设计
敏捷开发里有一个社会实践教学原则，就是我们不要过度设计，开发的价值不在于写出漂亮的代码，在于企业实现中国产品并支撑其正常工作运转，在能实现公司产品服务功能的前提下，代码逻辑其实是越简单越好，简单往往就意味着高可靠性+低维护管理成本，如果将来发展需要不断扩展功能，可以同时通过信息修改和重构实现。
当然，简单并不意味着随意。 很容易使事情复杂，但很难使事情简单。 可以实现逻辑清晰，线程安全，内存安全，还可以方便修改和扩展，还可以保持代码简洁，其实测试能力更强..
事实上，不仅在新功能的开发，以避免过度设计，维护与旧代码的扩张，但也注意到，代码可以正常运行，代码是很好的，我觉得在维护旧代码的事实上，应用开放封闭原则，必须改变，不改变旧的代码折叠，它是开放的，可以修改;该代码的正常运行，即使你再一次觉得痒难看，这是封闭的，不能修改。
回到那句话，开发的价值不在于写出一个漂亮的代码，在于可以实现企业产品并支撑其正常工作运转
欢迎关注我们的公众号
