首页>>新闻>>郑州App开发,怎样又快又稳又清晰

郑州App开发,怎样又快又稳又清晰

19-03-25

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

速度、质量和可维护性

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

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

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

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

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

异常处理

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

  • 提前考虑异常处理,在写正常流程的业务代码之前,先考虑异常,“未虑胜,先虑败”,沿着业务流程分支,先把异常情况都处理掉,例如获取在线数据显示一个列表,先考虑网络异常、服务器报错、数据失败等异常情况,并依次给出相应提示,最后才处理数据正常的情况,你本来就要写正常业务代码和异常处理代码,你只需要调换一下工作的先后顺序,其实你投入的开发时间没有增加,但是你的效率却大大提升了,因为一旦出现异常,我们可以迅速判断异常原因,节省大量时间。
    这样做还有一个好处,在你的思维陷入复杂的业务逻辑之前,先处理相对简单的异常分支,可以避免你被业务逻辑搞到大脑缺氧后,再回来处理异常分支时一时疏忽手滑,写错或者写漏异常处理。

  • 隔离前后台对接的数据接口,最好不要直接使用后台提供的数据,中间加一层映射,一方面,如果后台数据出了问题(数据异常、变更字段等),你在映射数据时就能发现和定位问题;另一方面,也有利于你采用更适合App的数据形式进行数据持久化。
    另外,建议做一个接口录入与检查工具,形式不论,但要能轻松地维护前后台接口,最好能自动检测接口反馈是否正常(服务器负载过大、字段变更、第三方服务过期等)。

  • 异常信息的收集、汇总和数据持久化
    如果出现异常,最重要的是采集到异常代码行(如MainActivity第61行)和异常原因(如空指针异常),并记录为本地文件以备上传和查看

结构分层

使用框架是必须的,Model层,View层必须职责单一,至于使用MVP、MVVM还是别的什么就看个人偏好和项目需要了。
个人比较偏好MVP,感兴趣可以看一看MVP框架的演化,当然,Rx链式编程也不错。
个人在结构分层上,有这么几个经验:

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

  • 松耦合的Activity,界面应该是与业务相关最低的,主要提供一个显示载体,并触发生命周期处理,Activity应该可以很容易地被替换掉。

  • 独立且方便测试的业务层,业务层应该可以实现自动化测试,这非常重要,即使你不去实施自动化测试,把代码写成可以自动化测试的,也能帮你优化代码,该抽象的抽象,该剥离的剥离。

  • 必要时抽象特殊控件,如果控件需要复用,就不要让控件融合进Activity,而是抽象为独立的显示控件,这样既能解耦合,又方便复用。

通用库的建立与维护

我们知道,项目管理有四个要素,时间、成本、范围、质量,这四个要素一般是不能兼得的,要时间,就得砍一些范围的项目目标,降成本,就容易牺牲质量,等等,不过,建立和维护通用库,却能同时对四个要素都有好处。

  • 加快开发速度,专注于具体业务(时间)
    降低团队成员熟悉项目的成本,为新业务开发提供基础,加快开发迭代速度,有利于更快地发布版本

  • 提高代码复用率,降低开发投入(成本)
    稳定的公共模块采用依赖组件库方式,提供给各个业务线协作使用,减少重复开发和升级维护工作量

  • 提升开发效率,更容易实现项目目标(范围)
    对已实现过的功能/业务,抽象出通用模块,再有类似的需求,能够迅速实现,更容易实现项目的业务需求

  • 提升产品质量,持续改进通用功能(质量)
    频繁使用的功能/业务模块采用组件复用方式,更有利于暴露缺陷,一处修改,多处受益,提高产品质量

代码注释

一般来说,程序员看自己一个月前写的代码,是完全陌生的,我也一样,基本上过一个月就没印象了,但是如果要修改/扩展怎么办,这时候,就得看代码注释了。
就个人经验而言,有这么几个地方,一定要写注释:

  • 接口,特别是MVP的Contract接口,这里面基本定义了你的主要业务行为,谁来加载数据,谁来显示数据,谁触发的下一步操作,这些内容写明白了,以后读代码,只要看接口就知道主要业务是怎么回事儿了。

  • 服务、广播等,服务和广播因为没有界面,容易游离在业务逻辑链条之外,在业务逻辑上缺少上下文,就必须有详尽的注释,说明其业务场景。

  • 初始化、注入等,如果自定义了一些扩展的功能或控件,要求执行某些初始化函数,或者要注入特定功能的,就必须写好注释,提示调用者进行必要的操作。

  • TODO,工作总要排优先级的,有些工作暂时延后,自己记录是没用的,团队开发最终用的还是代码,所以一定要写TODO,提示开发者,这里是未完成的状态,避免不必要的误会和延误。

    不要过度设计

    敏捷开发里有一个实践原则,就是不要过度设计,开发的价值不在于写出漂亮的代码,在于实现产品并支撑其正常运转,在能实现产品功能的前提下,代码逻辑其实是越简单越好,简单往往就意味着高可靠性+低维护成本,如果将来需要扩展功能,可以通过修改和重构实现。
    当然,简单并不意味着随意,要把事件做复杂很容易,要做简单却很难。能做到逻辑清晰、线程安全、内存安全,又容易修改和扩展的同时,还能保持代码简洁,其实反而更考验功力的。
    其实不仅在开发新功能时要避免过度设计,在维护和扩展旧代码时,也要注意,能正常运行的代码,都是好代码,我觉得在维护旧代码时,其实也适用开放封闭原则,对不得不改,不改就崩的旧代码,是开放的,可以修改的;对能正常运行的代码,哪怕你觉得再难看再手痒,那也是封闭的,是不可以修改的。
    回到那句话,开发的价值不在于写出漂亮的代码,在于实现产品并支撑其正常运转。




   网站建设知识>>

移动互联网时代,小微企业仍需要官网

标准的企业网站,客户需要提供什么资料?

   app开发知识>>

郑州APP软件开发:App Store 审核被拒的8种原因

App开发,不快等于Die

   运营服务>>

网站seo怎么拓展有效的长尾关键词?

网站内容更新后,必须要做的事!