App开发,应该要明确目标,清楚自己要什么

速度、质量和维护要求实际上是快速、稳定、清晰的要求。
速度:速度其实是最简单的,或者最容易知道能不能做,熟悉的Android开发的朋友知道,如果能理解业务逻辑,不受干扰地投入开发,开发速度快,一般规模的App可以在1~2周内完成。
稳定性:稳定性不快,可以简单地用时间进行实时的量化评价,我们知道大量错误出现后稳定性不稳定,但一般急速加速容易出现大量错误。事实上,安卓的常见问题只不过是内存、异步、响应等。排除和解决这些问题非常容易。如何确保这些问题不会发生?

App开发,应该要明确目标,清楚自己要什么


清晰

清晰是最困难的,可以通过时间量化,稳定地通过错误统计量化,但清晰是难以量化的,代码审查和可扩展性是主观评价,而且相当滞后,多数情况下,需要实现扩展,更换代码
对于开发者来说,如何快速稳定地开发App,在这里整理了我的一些心得。


有限的参与业务设计
从责任分工来看,业务设计是运营部门和产品经理的工作,确实不应该由研究开发负责,但我说的是参加,研究开发(包括测试)应该尽快参加业务设计,一方面事先发现问题,另一方面可以引导和提出技术路线。
研发参与设计,可以避免许多问题,如通信压力、加载速度、延迟时间、硬件负载等移动开发特有问题,不能指望运营和产品能够像专业研发一样面俱到,考虑周翔。
另一方面,研发参与设计还可以引导技术技术路线。例如,采用原始应用程序、混合应用程序、ReactNative形式、单用户系统或多用户系统、收费形式等。
在实际操作中,业务设计可能会发现收费形式、异常提示、业务逻辑严密性等漏洞。
当然,参加设计必然占有研究开发的时间,有人感到不满。我觉得这是为了替产品而工作的,但实际上研究开发参加了设计,节省了自己的时间。无论产品是怎样设计的,最终都需要技术来实现研究开发。如果设计有问题,修改代码的投入比改变产品文件的投入要多。
当然,公司水平也需要明确的定位,研究开发对设计的投入必须是有限的指导性的,大量将研究开发投入设计工作是另一种形式的浪费。


异常处理
在实际开发过程中,除了错误,实际上占了相当多的工作量,有时开发计划很好。一些奇怪的错误必须迟到半天,所谓的码字5分钟,错误2小时也是如此。因此,能否尽快处理异常对开发效率有很大影响。
处理异常,我有几个心得
事先考虑异常处理,在写正常流程的业务代码之前,先考虑异常,不考虑胜利,先考虑失败,沿着业务流程的分支,先处理异常情况,比如在线数据显示列表,先考虑网络异常、服务器错误、数据失败等异常情况,然后依次提出相应的提示,最后处理数据正常情况
这样做还有一个好处,在你的思维陷入复杂的业务逻辑之前,你可以先处理一个相对简单的异常分支,这样你就可以避免在业务逻辑中得到脑缺氧后,当你回来处理异常分支时,你可以暂时不小心手滑,写错或者写错了异常处理。
隔离前后台对接的数据界面,最好不要直接使用后台提供的数据。另一方面,如果后台数据有问题(数据异常、字段变更等),则在反映数据时可以发现和定位问题,另一方面,也有助于使用适合App的数据形式进行数据持续化。
另外,建议制作接口输入和检查工具,无论形式如何,如果能够简单地维前后台接口,自动检查接口反馈是否正常(服务器负荷过大,字段变更,第三方服务过期等)。


结构是分层的
高内聚数据层,将数据读写相关处理、网络读写、写、当地读写、缓存数据等包括模拟数据在内,集中在数据层,通过召回和链接调用等方式将数据投入业务层,通过多版本机制切换模拟数据和真实数据。
松耦合的Activity,界面应与业务最低,主要提供显示载体,触发生命周期处理,Activity应易于更换。
独立方便测试的业务层,业务层应该能够实现自动化测试,这是非常重要的,即使不实施自动化测试,也可以将代码写成自动化测试,优化代码,抽象化,剥离。
必要时抽象特殊控制,如果控制需要再利用,不要将控制融入Activity,而是抽象独立的显示控制,可以解除耦合,使再利用变得容易。

App开发,应该要明确目标,清楚自己要什么

如若转载,请注明出处:纯敬科技https://www.purexm.com/article/467.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注