第一，前言。

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

速度，质量、质量和可维护性。

对速度、质量和可维护性的要求实际上是快速、稳定和清晰的要求。

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

稳定性：稳定性不同于快速性，可以简单的用时间进行即时量化评估，我们要等到大量bug出现后，才知道稳定性，但一般赶工速度一快，就容易出现大量bug。事实上，Android常见的问题不外乎、响应等，要排除和解决这些问题很容易，难的是如何保证不会出现这些问题。

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

对开发人员而言，如何才能快速、稳定、清晰地开发App，这里梳理一下我的几点心得。

第三，有限参与业务设计。

从职责分工来看，业务设计是运营部门和产品经理的工作，确实不应该由研究开发负责，但我说的是参加，研究开发(包括测试)应该尽快参加业务设计，一方面发现问题，另一方面引导技术路线

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

另一方面，参与研发设计也可以引导技术路线，如本地应用、混合应用或ReactNative，单用户系统或多用户系统，收费形式等。

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

当然，参与设计必然会占用R&D的时间。有些人会感到委屈，觉得这是为产品做了自己的工作。然而，实际上，R&D参与设计节省了自己的时间，因为无论产品如何设计，最终都需要技术来实现R&D。如果设计有问题，你修改代码的投资比产品更改文档的投资大得多。

当然，公司层面也要有明确的定位，研发对设计的投入，必须是有限的指导，如果大量的研发投入到设计工作中，就是另一种浪费。

第四，异常处理。

在实际开发过程中，除了bug，实际上占据了相当大的工作量。有时候好好开发计划，因为几个奇怪的bug要耽误半天。所谓码5分钟，排错两个小时也是如此。所以能否尽快处理异常，对开发效率影响很大。

处理异常，我有几个经验:

事先考虑异常处理，在写正常流程的业务代码之前，先考虑异常，不考虑胜利，先考虑失败，沿着业务流程的分支，先处理异常情况。例如，在线数据显示列表，首先考虑网络异常、服务器错误、数据失败等异常情况，依次提出相应的提示，最后处理数据的正常情况。本来就要写正常的业务代码和异常的处理代码。只要更换工作顺序，实际上投入的开发时间没有增加，但你的效率大幅度提高。如果发生异常，我们就能迅速判断异常原因，节省很多时间。

这也有一个好处，在你的思维陷入复杂的商业逻辑之前，先处理一个相对简单的异常分支，这样可以避免你在被商业逻辑弄到脑缺氧之后，再回来处理异常分支时一时疏忽手滑、写错或写错。

隔离前后台对接的数据接口，最好不要直接使用后台提供的数据，中间加一层映射。一方面，如果后台数据有问题(数据异常、字段变化等)。)，你可以在映射数据时找到并定位；另一方面，它也有助于你使用更适合应用程序的数据形式来持续数据。

*个人在结构层面上有以下经验:

高度聚集的数据层，将与数据读写相关的处理、网络读写、本地读写、缓存数据等，包括模拟数据，都集中到数据层，通过回调或链式调用向业务层抛出数据，通过多版机制切换模拟数据和真实数据。

松耦合的Activity界面应该与业务关系最小，主要提供显示载体，触发生命周期处理。Activity应该很容易被替换。

对于独立且便于测试的业务层来说，业务层应该能够实现自动测试，这一点很重要，即使你不去实施自动测试，把代码写成可以自动测试的，也可以帮助你优化代码，的，剥离的。

如有必要，抽象特殊控制。如果控制需要重复使用，不要将控制集成到Activity中，而是将抽象集成到独立的显示控制样既可以解耦，又方便重复使用。

第五，不要过度设计。

敏捷性开发有一个实用的原则，就是不要过度设计，开发的价值不在于写出漂亮的代码，而在于实现产品并支持其正常运行，在实现产品功能的前提下，代码逻辑其实是越简单越好，简单性往往意味着高可靠性+低维护成本，如果将来需要扩展功能，可以通过修改和重构来实现。

当然，简单并不意味着随意，把事件做得复杂而简单，做得简单而困难。实现逻辑清晰、线程安全、内存安全、易于修改和扩展和扩展，同时又能保持代码简洁，其实更考验功力。

事实上，不仅在开发新功能时要避免过度设计，在维护和扩展旧代码时，还要注意，能够正常运行的代码，都是好代码，我觉得在维护旧代码时，实际上也适用了开封原则，对于不得不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变、不改变。

回到那句话，开发的价值不在于写出漂亮的代码，而在于实现产品并支持其正常运行。

第六，建立和维护通用库。

众所周知，项目管理有四个要素：时间、成本、范围、质量，这四个要素一般是不能兼得的，要时间，就要砍掉一些范围的项目目标，降低成本，就容易牺牲质量，等等，虽然，建立和维护通用库，但同时也有利于四个要素。

加快开发速度，专注于具体业务(时间)

降低团队成员熟悉项目的成本，为新业务发展提供基础，加快开发迭代，有利于更快发布版本。

提高代码再利用率，降低开发投资(成本)

稳定的公共模块依靠组件库提供给各业务线合作，减少重复开发和升级维护工作量。

提高开发效率，更容易实现项目目标(范围)

对于已经实现的功能/业务，抽象出通用模块，再有类似的需求，可以快速实现，更容易实现项目的业务需求。

提高产品质量，不断改善通用功能(质量)

经常使用的功能/业务模块采用组件再利用方式，有利于暴露缺陷，一个修改，多个利益，提高产品质量。

第七，工具和模板等。

事实上，谈到提高效率，前面的许多经验因为需要在实际开发中慢慢体会，很难快速上手，而是工具模板，真正见效快，一次安装，终身受益：)

就我的经验而言，最有帮助的是开发效率，包括代码模板、常用配置和开发插件，以及著名程序员在线交友网站Github。

第八，代码注释。

一般而言，程序员看自己一个月前写的代码，是完全陌生的，我也一样，基本上一个月后就没有印象了，但如果要修改/扩展怎么办，此时，必须看代码注释。就个人经验而言，有几个地方，请务必写下注释：

界面，尤其是MVP的Contract界面，基本上定义了你的主要业务行为，谁来加载数据，谁来显示数据，谁来触发下一个操作，这些内容清楚了，以后看代码，只要看界面就知道主要业务是怎么回事了。

服务、广播等。由于没有界面，服务和广播很容易离开业务逻辑链。如果业务逻辑缺乏上下文，必须有详细的注释来解释其业务场景。

初始化、注入等。，如果定制一些扩展功能或控制，要求执行一些初始功能或注入特定功能，则必须写下注释，并提示调用者进行必要的操作。

TODO，工作总是优先，有些工作暂时推迟，自己的记录没用，团队开发最终使用的是代码，所以写TODO，提示开发者，这里是未完成的状态，避免不必要的误解和延误。

标签： APP开发 程序开发 开发应用软件