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

一: 在开发中，经常能够遇到共用同一个界面的情况,一般情况下，我们会根据传入的model去做数据处理和保存。

 当然如果不存在复用的情况下,根本不需要有太多的考虑，这里不考虑小应用的情况。

 在追求界面复用的情况下，一个应用出现一个界面复用两次，三次都是很常见的吧！那么我们还是根据传入的model去处理，这样对后来阅读代码的人来说，是一件很难受的事情。如何处理，才能少出错或者不出错，应该是我们的追求。

 对于复杂的逻辑，拆分往往能起到清晰明了的作用。这里是用枚举和swith case 去处理，每一个不通过界面传递过来的处理和回调问题。

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

 

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

最后在获得数据时候，需要将每个参数都看一遍。保证上传参数没有问题。当下意识去提前写某些东西的时候，其实你也就对可能发生的问题，有了提前的预估，在这之前就提前标记。 

最近在开发App Extension，手动撸请求的时候，一定要标记根请求地址，防止本地请求和线上请求混淆，避免在开发过程中一直出现找不到服务地址的问题。

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

 

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

5: 编码记得先写文档

 

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

 

刚开始工作的时候，总是一接到任务就马上开始写代码，结果可能遇到了很多问题，例如：

1. 需求本身就存在问题，代码写到一半以后才发现

2. 部分需求没有表达清楚，发现的时候才去沟通，结果发现时间不够，或者跟之前的代码产生冲突

3. 代码写到一半时，发现自己思路不对或者不清晰了

 

最后很有可能导致项目延期。

如果在开发前就把需求分解好，把问题沟通清楚，把要做的点一个个列下来，就能大大地避免这些问题。

 

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

 

6.实现需求，最好先写Demo.

用 Demo 来实现一个需求是最快的，因为它运行快，可以随意修改，而且代码量少，如果实现过程出现问题，很容易就可以定位到原因,保证问题能够快速的被找到。也就是隔离法。

先建立一个 Demo，然后把需要的资源移植过来，把功能实现以后，再移植到项目中，这样可以节省不少开发时间.

 

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