iOS开发自我开发准则之-逻辑严谨性

最新推荐文章于 2022-08-03 13:01:30 发布

星辰为伊人

最新推荐文章于 2022-08-03 13:01:30 发布

阅读量1k

点赞数 1

分类专栏： iOS开发-自我规范文章标签： ios 流程控制业务流程代码逻辑封装

本文链接：https://blog.csdn.net/James_1_2_1_1/article/details/73277441

版权

iOS开发-自我规范专栏收录该内容

3 篇文章 0 订阅

订阅专栏

我们日常研发过程中能涉及到的逻辑有太多太多，我在这里总结一下我在开发中遇到的一些要注意的逻辑方面。

业务逻辑

每个公司或个人的没个产品的业务逻辑都有不同，但我们当得到产品原型时，逻辑不一定是完美的，人人都会犯错，产品人员也不一定会把逻辑梳理的毫无漏洞，这时就需要我们在研发过程中去梳理逻辑，查缺补漏，才能保证在整个产品业务流程和使用中不会出现大的逻辑问题。更多的就不再细说，毕竟这是产品的锅。如果有人想往产品方向发展，那么可以在这方面的逻辑上多动动脑筋。

通用功能逻辑

这里所说的通用逻辑是指，在一些比较通用的功能中存在的逻辑严谨性，例如数据请求，下拉刷新，上拉加载，页面跳转，推送消息处理等。

我总结一些我所遇到的容易出问题的地方。

数据请求时容易出现问题的地方有：

参数封装方式：一般我们在使用请求时都会把参数封装成字典传入请求方法，但存在方式问题，如果直接在请求前创建字典进行参数写入，一定要进行非空判断，但如果将参数封装写成一个model内部的通用方法的话，就会省事很多，直接创建请求model给对应字段赋值，传入即可。
请求之后的数据解析：由于现在有很多第三方的模型工具库，在解析JSON转model时变的方便很多，即使有问题一般也不会崩溃。要注意的是在解析时的对应字段和层级一定要找准。

下拉刷新时容易出现的问题：

流程控制变量是否被重置：在开发过程中，我们获取数据的接口一般只有一个，因此我们下拉和上拉所使用的都是同一个接口，只是参数不同。在下拉时相当于将当期页面所有数据重新加载，因此所有的流程控制变量比如页码，数据源数组等都要重置成进入页面时的状态，以保证数据的刷新。
是否有自定义刷新动画：当今的刷新一般都会用MJRefresh，当然里面可以设置动画图片，我这里说的是放弃MJ的刷新效果，以自定义的刷新动画来进行的下拉刷新。要注意的是这个动画无论是用第三方还是自己实现，动画的执行过程都不要放在主线程中，否则会影响主线程的UI刷新。

上拉加载时容易出现问题：

加载后的数据有效性判断：这个有效性之的是，是否是重复数据，是否类型错误等。在判断之后再将数据插入到数据源数组中，因为如果不判断，那么只要进了数据源，就会被展示在页面上。
加载后的数据排序问题：首先，这个问题一般会交给后台进行处理，因为如果本地对数组内部元素按照某个规则排序的话，那么会占不必要的系统运算资源。但如果后台不给处理或者只做了简单处理，我们就要考虑解决方案了。这个问题一般出现在有序展示的列表中，当列表以某种规则进行排序展示后，有新的数据进入后台，当新数据总数量超过一页之后，如果本地请求上拉加载，那么这时请求来的数据将不再是当前页面应该出现的下一页，而是后台将新数据重新排列后的下一页的数据，如果不处理，则会导致展示页面新数据会在老数据的后面出现，并包含重复数据。解决方式是在上拉加载时，将请求到的有效数据存入数组，按照规则将数组重新排序并去除重复数据，静默刷新列表，并停留在当前位置。
删除某条或某几条数据后加载数据造成的数据丢失问题：我们在对列表数据进行删除时，一般会先调用删除单条数据的请求，当返回成功后再删除本地数据源中的数据和对应位置的cell。但只是这样处理是不够的，因为这时后台中的数据已被删除，当我们上拉加载时，数据会以页为单位进行分组，以我们传的页码为标志去返回对应页的数据，这时由于后台中删除数据的位置已被下一条位置填补，那么在分页时，之后每条数据的位置都会比我们展示的位置提前一位，这是加载出来的下一页的数据就不再是删除之前的下一页的数据，而是除了删除前下一页第一条以后的数据，那么就会造成该条数据不会展示在列表中。解决方式就是，只要在删除动作之前获取一下下一页数据，然后取第一条加入数组，再进行删除动作即可。或者由后台处理，在删除接口返回成功的同时将下一页中会丢失的数据一起返回，在插入数据源中也可以解决问题。有可能的话尽量采用后一种处理方式，因为后台的数据会时时刷新，也许你获取到的数据未必就是下一页会丢失的数据，因此由后台处理比较妥当。

先这么多，以后补充。

代码逻辑

一个人的代码逻辑性体现了一个人的整体编程水平。我们在平时的研发过程中，如果出现了大量重复代码，过多的判断，多层的循环嵌套，等等等等比较冗余的代码量时，我们就要考虑一个问题：难道真的非这么实现不可吗？

其实，也不是说一定所有的功能都有更简便的实现方式，只是说在当我们重复做同一件事的时候，确实有必要考虑一下代码的逻辑性。

我所理解的代码逻辑性包括：

1. 代码简易度/代码可读性：

这不仅仅包括变量的有意义命名和驼峰写法这么简单。试想一下，当你接收一个项目时，哦不，就算是去看你一个月前写的代码如果注释写的不是那么详细或者就根本没有注释，你在阅读代码的时候就会变得非常吃力。原因很简单，首先英文不是我们的第一语言，我们不可能看英文和看中文一样不需思考就明白什么意思。其次，即使当时你写代码的时候逻辑和思路很清晰，在过了一段时间后，也只能大致想起当时的大概逻辑。更不用说去看别人写的一些过度冗余的代码了。

这里也有一句名言，编程语言是写给人看的，不是只写给电脑看的。

2. 代码的封装度和复用性：

某位前辈曾经说过：当一段代码被你复制粘贴超过3次时，你就要考虑是否要讲其封装起来了。

封装有两个好处就是易读和易用。比起看多行复杂逻辑的代码，看一行可以调用的方法更简单，因为只要明白这段代码是起什么作用的就可以了。将代码封装后，使用也变得更加方便，因为调用一个方法，比复制粘贴多行代码更快捷。

封装是面向对象编程的核心思想之一，即把一个类应该有的功能和作用包起来，留出可调用的接口，方便使用。

这也是为什么那些写第三方库的神人们都会把功能一个一个封装成方法，然后只留出接口供人使用。

有人说了，在当今MVC横行的时代，控制器会不可避免的写的很大很复杂，我也想封装，但功能就是那么多，也没办法。

当然了，在MVC模式中，控制器起到了关联数据和展示的作用，因此，数据获取，逻辑处理，展示方式都会在控制器中进行，这使得控制器文件不可避免的变得巨大无比，MVC也因此得到了另一个别名：Massive View Controller（巨型视图控制器）。

但是，在现在的开发中，我们的M层其实不仅仅可以作为数据层存在，除了储存数据以外，还可以将一些业务逻辑写到里面，封装成方法，对数据进行处理。这样就完成了数据模型到业务模型的转变。

至于View层，我们可以将View抽离出来单独作为一个类来进行编写，在控制器内只进行view的创建和展示，不再对view内部如何进行展示进行操作，这样就减少了更多控制器中繁杂的代码。

3. 尽量减少多层循环的嵌套：

循环，是大家在处理数据时不可避免会用到的一个东西，但这种东西一旦被嵌套使用，那么资源的消耗也是成次方倍的增长，也就是所谓的算法运算复杂度。