我的iOS高效编程秘诀 — 坚持编程习惯
习惯会影响一个人的做事方式，进而直接影响做事效率。我常常在项目完成后进行自我总结，反思哪些方面做得好，哪些方面有待改进。随后，我会将一些行之有效的流程记录下来，并重新应用到编程工作中。那些能够长期坚持执行的流程，逐渐成为了我的编程习惯，这些良好习惯成就了我高效的编程工作。
一、轻文档先行
1. 轻文档的定义
轻文档并非需要按照标准的软件工程知识编写需求分析、架构设计、模块设计、流程图、时序图等文档。它采用较为自由的方式，将你要做的事情以及做事的步骤清晰描述出来即可。这种文档不限制格式，你甚至可以手写在笔记本上，只要自己能看懂，且在开发过程中可随时查阅就行。
2. 写文档的原因
初入职场时，我总是一接到任务就立刻开始编写代码，结果遭遇了诸多问题：
- 需求本身存在问题，往往在代码写到一半时才发现。
- 部分需求表述不清，发现问题后再去沟通，可能会出现时间不够用，或者与之前代码产生冲突的情况。
- 代码编写到中途，发现自己的思路出现偏差或不够清晰。
这些问题最终很可能导致项目延期。如果在开发前就将需求分解好，把问题沟通清楚，并将需要完成的要点逐一列出，就能大大避免上述问题的发生。
3. 文档的内容
① 准备工作
在开始开发前，需要明确所需的准备工作。以开发一个发送消息的界面为例，需要做好以下准备：
- 接口协议
- 测试环境
- 测试账号
提前做好准备工作通常能提高开发效率。将这些内容记录下来，是为了在开发过程中能够快速检索。若等到开发开始后再去查看聊天记录或向相关人员询问，会浪费大量时间。
② 罗列小功能点
以发送消息界面为例，存在许多小功能点，如：
- 发送界面
- 发送的数据接口
- 文本字数限制
进一步思考，还可能会遇到以下问题：
- 是否需要登录？若未登录，是否要引导登录。
- 对于发送失败的情况，应如何处理。
- 字数超出限制时，如何进行交互。
- 用户重复发送相同文本，是否需要过滤。
- 如何处理数据接口的错误码。
记录下这些小功能点，并与产品经理沟通清楚后，就可以初步评估开发周期，同时明确该需求包含多少小功能，以及如何划分模块和构建内部流程。对于部分流程复杂的功能，可以绘制流程图辅助理解。
③ 记录需求改动点
如果是全新需求且与以往版本无关，可忽略此部分。但如果该需求会对以前的代码产生影响，则需要记录改动部分。因为项目中的很多 bug 是在代码修改过程中产生的，列出改动点能让自己更清楚新功能带来的影响，从而减少低级 bug 的出现。
例如，新增一个发送图片的功能，该功能会影响聊天窗口的展示和键盘的使用，这些改动点都需要记录下来。一方面可以辅助思考是否遗漏了小功能点，另一方面在自测试时需要对聊天窗口展示和键盘切换进行覆盖测试。
④ 罗列自测试内容
编码完成后，一定要进行自测试。自测试越仔细，越能提前发现并修复 bug。若由测试人员发现 bug 后再提交给自己解决，效率往往较低。
以发送消息功能为例，自测内容包括：
- 正常发送消息
- 未登录时点击发送
- 字数超出限制
- 没有网络时点击发送
- 网络很差时不断点击发送
二、开始编码
1. 重写还是保持不变
在处理新需求时，常常会面临以下问题：
- 以前的模块编写质量不佳，想要重新编写。
- 类似的需求，之前采用了某种实现方式，这次想尝试新的方法。
考虑这些问题表明你有追求进步的意愿，但在做决定之前，最好先考虑以下因素：
- 重写模块可能会牵一发而动全身，需要考虑改动可能带来的影响以及解决这些问题所需的时间。
- 使用新方案实现需求时，要确保新方案已经经过仔细验证，否则可能会带来新问题。
实际上，保持现状也有一些优势：
- 可以比之前的开发速度更快，因为你对现有代码更加熟悉。
- 不会引入新的问题。
综合考虑上述因素后，基本就能确定是重写还是保持现状。不过，保持现状并不意味着放弃追求进步，你可以利用业余时间验证自己的方案，待其稳定可行后，随时都可以进行重写。
2. 实现需求，Demo 先行
使用 Demo 实现需求是最快的方式。Demo 运行速度快，可随意修改，且代码量少。若实现过程中出现问题，很容易定位原因。
先创建一个 Demo，将所需资源移植过来，实现功能后再移植到项目中，这样可以节省大量开发时间。
3. 借助工具
① 代码模板（File Template）
在创建视图、控制器或 Model 时，可能会有一些固定的函数和属性需要定义或重写。使用 Xcode 可以创建代码模板，在创建类文件时一键生成这些代码，从而提高开发效率。
② 代码片段（Code Snippet）
一般可重用的代码会封装成类或函数以便复用，但有些代码不适合封装，例如：
- 声明一个属性
- 创建一个线程
对于这类代码，我会将其制作成代码片段，通过 Xcode 的 Code Snippet 自动补充功能快速完成编码。例如，输入 @OperateThread 就可以直接完成创建一个操作队列的代码，大幅减少编码时间。
③ 自动注释工具（VVDocumenter）
这是一个可以一键创建注释模板的工具，能够减少编写注释所需的时间。
4. 适当添加注释
如果像官方 API 那样在所有地方都添加注释，工作量会大幅增加，需要额外的开发时间。而针对语义不明、有歧义的代码添加注释，反而能减少开发时间。
例如，对于属性 @property (nonatomic, assign) int64_t createTime;，仅从代码本身难以确定它是否为时间戳，以及时间戳的单位是秒还是毫秒。添加注释 /// 创建时间（时间戳 秒） 后，代码的含义就一目了然了。
三、自测
1. 先检查后自测
完成一个小功能后，先检查代码，再进行自测。因为代码能提供很多有用信息：
- 是否存在低级错误。
- 是否有难以发现的漏洞。
- 流程是否存在问题。
如果编码完成后立即进行自测，可能会陷入被动状态，例如界面显示异常、数据与预期不符、出现不该出现的内容等。此时再回过头调试代码、逐步修改，会非常耗时，因为编译和操作都需要时间，而且有些测试条件难以模拟。
2. 自测点要全部过一遍
虽然自测过程可能会让人觉得繁琐，浪费时间，但在这个阶段发现 bug 是最容易修复的。因为此时对代码的记忆最为清晰，能更容易找到问题所在。
四、总结
我的编程习惯是先用文档理清思路，然后开始编码，编码完成后检查代码并进行自测。这一习惯我一直沿用至今。
实际上，仅仅知道某个技巧并不能提升效率，只有坚持使用该技巧并形成习惯后，才能真正提高编程效率。