新闻动态

重庆app开发:对于app的速度、质量、可维护性都有哪些认知

2019-09-16 16:30:13

  前言


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


  速度、质量和可维护性


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


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


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


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


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


重庆app开发:对于app的速度、质量、可维护性都有哪些认知


  有限参与业务设计


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


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


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


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


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


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


  异常处理


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


  处理异常,我有这么几条心得:


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


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


  隔离前后台对接的数据接口,最好不要直接使用后台提供的数据,中间加一层映射,一方面,如果后台数据出了问题(数据异常、变更字段等),你在映射数据时就能发现和定位问题;另一方面,也有利于你采用更适合App的数据形式进行数据持久化。


  另外,建议做一个接口录入与检查工具,形式不论,但要能轻松地维护前后台接口,最好能自动检测接口反馈是否正常(服务器负载过大、字段变更、第三方服务过期等)。


  异常信息的收集、汇总和数据持久化


  如果出现异常,最重要的是采集到异常代码行(如MainActivity第61行)和异常原因(如空指针异常),并记录为本地文件以备上传和查看