iOS 如何写出更加严谨的应用

1,631 阅读4分钟
原文链接: www.jianshu.com

本文旨在介绍一些能够帮助大家避开一些开发误区的经验。

一: 在开发中,经常能够遇到共用同一个界面的情况,一般情况下,我们会根据传入的model去做数据处理和保存。
 当然如果不存在复用的情况下,根本不需要有太多的考虑,这里不考虑小应用的情况。
 在追求界面复用的情况下,一个应用出现一个界面复用两次,三次都是很常见的吧!那么我们还是根据传入的model去处理,这样对后来阅读代码的人来说,是一件很难受的事情。如何处理,才能少出错或者不出错,应该是我们的追求。
 对于复杂的逻辑,拆分往往能起到清晰明了的作用。这里是用枚举和swith case 去处理,每一个不通过界面传递过来的处理和回调问题。

068BDB0A-D94C-4A17-AA2B-9FC80B17DC67.png

B2CB5A7E-B49C-4CAE-AA25-21E920A37A36.png

屏幕快照 2016-12-19 下午9.49.29.png

这样下次不论谁读代码,都有一种清晰明了的感觉,不会出现调用的越多,传入的参数越多,逻辑越混乱的情况。

2:测试环境和正式环境一定要标注,保证自己不会忘。也算是给自己提醒。


5CD03FEB-52FF-451F-8BE6-EF1257C684EB.png

最后在获得数据时候,需要将每个参数都看一遍。保证上传参数没有问题。当下意识去提前写某些东西的时候,其实你也就对可能发生的问题,有了提前的预估,在这之前就提前标记。
最近在开发App Extension,手动撸请求的时候,一定要标记根请求地址,防止本地请求和线上请求混淆,避免在开发过程中一直出现找不到服务地址的问题。


51FED1EAE20FDB3603595D3D84940B29.png

D617633124031FA8FC8641634D8927B9.png

825EB95C-22D6-45ED-98A3-55B9072CE599.png

3:在开发迭代过程中,UI永远都是廉价的。每个版本都要删除一些不必要的控制器Controller去替换,或者当我们需要修改一些特定逻辑的时候,全局搜索,别忘记用。如果你觉得工程中的命名不符合Apple的开发规范,那么也别忘了一键替换所有类名。

4.冗余的界面需要统一的回调,统一的处理,统一返回给服务器。类似这样的界面总共19列,那么为了减少处理逻辑,统一处理,必不可少。先不说,这有多少人用,先看看如何处理的。


0FE9B13A3151F6DB614B4E334636C64B.png

E006558BA83759FD77127C84F702E33E.png

097D8289-4ABC-45E0-BC5C-6FF6D4E0E4E6.png

211971C6-BDC0-4437-9473-F95153B9B06A.png

5: 编码记得先写文档

   采用比较自由的方式,把你要做的事情,还有做事情的步骤描述清楚的文档。这样的文档不需要限制格式,甚至你可以手写在自己的笔记本上面,只要自己能看得懂,在开发过程中能够随时查阅就可以了。

  刚开始工作的时候,总是一接到任务就马上开始写代码,结果可能遇到了很多问题,例如:
  1. 需求本身就存在问题,代码写到一半以后才发现
  2. 部分需求没有表达清楚,发现的时候才去沟通,结果发现时间不够,或者跟之前的代码产生冲突
  3. 代码写到一半时,发现自己思路不对或者不清晰了
  最后很有可能导致项目延期。
  如果在开发前就把需求分解好,把问题沟通清楚,把要做的点一个个列下来,就能大大地避免这些问题。

  再比如,我们做App Extension,之前没做过,那么最开始的时候应该是收到通知任务 ----》 寻找开源项目(这一步需要多做功课,看的越多,熟悉的就多)------》根据开源项目,查看AppDeveloper 开发者文档 (尽量去读一遍,保证有个印象)-------》确定开发时间------完成工作。

6.实现需求,最好先写Demo.
  用 Demo 来实现一个需求是最快的,因为它运行快,可以随意修改,而且代码量少,如果实现过程出现问题,很容易就可以定位到原因,保证问题能够快速的被找到。也就是隔离法。
  先建立一个 Demo,然后把需要的资源移植过来,把功能实现以后,再移植到项目中,这样可以节省不少开发时间.

我的备忘录中,每天都有备忘的代码,确保自己不会忘。


屏幕快照 2016-12-19 下午10.30.03.png