公司动态

前言
开发者的价值，是经过技能和产品表现的，对于App开发来说，除了完成事务之外，最重要的莫过于开发的速度、质量和可保护性，速度决议你能否支撑公司抢占市场，质量决议你们能不能站稳位置不被灵敏踢走，可保护性决议你们继续前行时能否坚持轻快的脚步。

速度、质量和可保护性
对速度、质量和可保护性的要求，其实便是又快，又稳，又明晰的要求。
快：快其实是最简略做到，或许说最简略知道能不能做到的事情，了解的Android开发的朋友都知道，假如能理清事务逻辑，不受搅扰地投入开发，开发速度可以很快，一般一般规模的App，一到两周就能完成。

稳：稳不像快，可以简略地用时刻进行即时的量化评价，咱们要等很多bug呈现之后，才知道稳不稳，可是一般赶工速度一快起来，就很简略呈现很多bug。其实Android常见问题无非是内存、异步、呼应等，要排除和处理这些问题很简略，难的是怎样确保不呈现这些问题。
明晰：明晰是最难做到的，快可以经过时刻量化，稳可以经过bug计算量化，可是明晰是很难量化的，代码检查和可扩展性都是片面评价，而且适当滞后，许多情况下，往往要比及需求完成扩展，甚至换人接手代码时，才知道代码不明晰。

对于开发者来说，怎样才能又快又稳又明晰地开发App，这儿梳理了我的几点心得。
有限参加事务规划
从职责分工上，事务规划是运营部门和产品司理的作业，确实不应由研制担任，但我说的是参加，研制（包含测验）应当尽早参加事务规划，一方面提早发现问题，另一方面可以引导和主张技能道路。
研制参加规划，可以规避许多问题，例如通信压力、加载速度、延迟时刻、硬件负载等移动开发特有问题，不能盼望运营和产品能像专业的研制相同面面俱到，考虑周翔。
另一方面，研制参加规划还可以引导技能道路，例如选用原生App、混合App仍是ReactNative方法，选用单用户系统仍是多用户系统，选用什么收费方法等。
在实际操作中，事务规划诸如收费方法，反常提示，乃至于事务逻辑上的严密性，你都可能发现漏洞。
当然，参加规划必然会占用研制时刻，有人会觉得委屈，感觉这是替产品做了他们的作业，但其实研制参加规划，省下的仍是自己的时刻，由于无论产品怎么规划，最终都需求技能来研制完成，假如规划上出了问题，你修正代码的投入，可比产品改文档的那点儿投入大多了。
当然，公司层面也应有清楚的定位，研制对规划的投入，有必要是有限的指导性的，假如很多把研制投入到规划作业，便是另一种方法的浪费了。

反常处理
在实际开发过程中，除bug其实占了适当一部分作业量，有时候好好的开发计划，由于几个诡异的bug就得耽误半天，所谓“码字5分钟，排错两小时”是也。所以，能否尽早尽快处理反常，是十分影响开发功率的。
处理反常，我有这么几条心得：
提早考虑反常处理，在写正常流程的事务代码之前，先考虑反常，“未虑胜，先虑败”，沿着事务流程分支，先把反常情况都处理掉，例如获取在线数据显现一个列表，先考虑网络反常、服务器报错、数据失败等反常情况，并依次给出相应提示，最后才处理数据正常的情况，你本来就要写正常事务代码和反常处理代码，你只需求互换一下作业的先后顺序，其实你投入的开发时刻没有增加，可是你的功率却大大提高了，由于一旦呈现反常，咱们可以灵敏判断反常原因，节约很多时刻。
这样做还有一个优点，在你的思想陷入杂乱的事务逻辑之前，先处理相对简略的反常分支，可以防止你被事务逻辑搞到大脑缺氧后，再回来处理反常分支时一时疏忽手滑，写错或许写漏反常处理。
隔离前后台对接的数据接口，最好不要直接运用后台提供的数据，中间加一层映射，一方面，假如后台数据出了问题（数据反常、改变字段等），你在映射数据时就能发现和定位问题；另一方面，也有利于你选用更适合App的数据方法进行数据持久化。
另外，主张做一个接口录入与检查东西，方法不论，但要能轻松地保护前后台接口，最好能自动检测接口反馈是否正常（服务器负载过大、字段改变、第三方服务过期等）。
反常信息的收集、汇总和数据持久化
假如呈现反常，最重要的是收集到反常代码行(如MainActivity第61行)和反常原因(如空指针反常)，并记载为本地文件以备上传和检查

结构分层
运用结构是有必要的，Model层，View层有必要职责单一，至于运用MVP、MVVM仍是其他什么就看个人偏好和项目需求了。

个人在结构分层上，有这么几个经历：
高内聚的数据层，把与数据读写相关的处理，网络读写、本地读写、缓存数据等，包含模仿数据，都会集到数据层，经过回调或链式调用等方法抛出数据给事务层，经过多版别机制切换模仿数据和真实数据。

松耦合的Activity，界面应该是与事务相关最低的，首要提供一个显现载体，并触发生命周期处理，Activity应该可以很简略地被替换掉。
独立且便利测验的事务层，事务层应该可以完成自动化测验，这十分重要，即便你不去实施自动化测验，把代码写成可以自动化测验的，也能帮你优化代码，该笼统的笼统，该剥离的剥离。
必要时笼统特殊控件，假如控件需求复用，就不要让控件融合进Activity，而是笼统为独立的显现控件，这样既能解耦合，又便利复用。

不要过度规划
灵敏开发里有一个实践原则，便是不要过度规划，开发的价值不在于写出漂亮的代码，在于完成产品并支撑其正常运转，在能完成产品功用的前提下，代码逻辑其实是越简略越好，简略往往就意味着高可靠性+低保护本钱，假如将来需求扩展功用，可以经过修正和重构完成。
当然，简略并不意味着随意，要把事件做杂乱很简略，要做简略却很难。能做到逻辑明晰、线程安全、内存安全，又简略修正和扩展的同时，还能坚持代码简练，其实反而更考验功力的。

其实不仅在开发新功用时要防止过度规划，在保护和扩展旧代码时，也要留意，能正常运转的代码，都是好代码，我觉得在保护旧代码时，其实也适用敞开关闭原则，对不得不改，不改就崩的旧代码，是敞开的，可以修正的；对能正常运转的代码，哪怕你觉得再丑陋再手痒，那也是关闭的，是不可以修正的。
回到那句话，开发的价值不在于写出漂亮的代码，在于完成产品并支撑其正常运转。

通用库的建立与保护
咱们知道，项目管理有四个要素，时刻、本钱、范围、质量，这四个要素一般是不能兼得的，要时刻，就得砍一些范围的项目方针，降本钱，就简略献身质量，等等，不过，建立和保护通用库，却能同时对四个要素都有优点。
加快开发速度，专注于具体事务（时刻）
下降团队成员了解项目的本钱，为新事务开发提供基础，加快开发迭代速度，有利于更快地发布版别
进步代码复用率，下降开发投入（本钱）
稳定的公共模块选用依赖组件库方法，提供给各个事务线协作运用，减少重复开发和晋级保护作业量
提高开发功率，更简略完成项目方针（范围）
对已完成过的功用/事务，笼统出通用模块，再有类似的需求，可以 灵敏完成，更简略完成项目的事务需求
提高产品质量，继续改善通用功用（质量）
频频运用的功用/事务模块选用组件复用方法，更有利于暴露缺点， 一处修正，多处受益，进步产品质量