坚持好的编程习惯，有助于提高你的开发效率。

　　行为决定习惯、习惯决定性格、性格决定命运。习惯能载着你走向成功，也能驮着你滑向失败。习惯的力量是惊人的，三十五岁以前养成的习惯决定着你是否成功。接下来我将从三方面展开说明如何培养一个好的编程习惯。

　　第一、编程前（轻文档先行）

　　　　这里特别说明所谓的文档先行指的是“轻”文档的编写，因为过于详细的文档会让我们感到烦躁，反而起不到提高效率的作用。

　　　　1、为什么要文档先行？

　　　　　　刚刚进入开发工作中的年轻人经常见到的一种现象就是，交给你一个任务，你第一件事情要做的就是打开你的IDE，开始编写你的代码，结果往往会出现以下情况。

1. 1. 需求本身存在问题，代码开发一半后才发现，此时已经影响了项目的进度。
   2. 部分需求没有表达清楚，发现的时候才去沟通，结果导致开发时间不够用了，或者与部分功能产生冲突。　　　　　　
   3. 代码写到一半发现自己的思路不对或者不清晰了，开始重新调整代码。

　　　　以上的情况很有可能会导致项目的延期，倘若在开发前把需求分解好，把问题沟通清楚，把要做的点一个一个列出来，就能大大的避免这些问题。

　　　　2、文档都写什么？

　　　　　　1）、准备工作：在开始开发之前要准备什么，例如做一个发送消息的界面，需要有以下的准备：

　　　　　　　　a、确定接口协议

　　　　　　　　b、配好测试环境

　　　　　　　　c、配好测试账号

　　　　　　准备工作提前做好，往往会加快效率。为什么要把这些内容记录下来，是为了在开发过程中可以快速检索。如果等到开始开发以后再去查聊天记录，或者是找相关人员询问，那就慢了。

　　　　　　2）、列出需要做的功能点：例如做一个发送消息的界面，就有很多小功能点：

　　　　　　　　a、发送界面

　　　　　　　　b、发送的数据接口

　　　　　　　　c、文本字数限制等

　　　　　　　　d、是否需要登录？如果未登录，是否要引导登录

　　　　　　　　e、对于发送失败的情况，要如何处理？

　　　　　　　　f、字数超出限制时，如何交互？

　　　　　　　　等等...

　　　　　　当你记录下这些功能点，并且跟产品经理沟通清楚以后，你的开发周期已经可以初步评估了，并且这时候也已经弄清楚这个需求有多少小功能，需要怎么划分模块，怎么构建内部流程。对于部分流程复杂的功能，可以画一下流程图辅助理解。

　　　　　　3）、记录这个需求的改动：当然这个是针对功能升级的时候用到的，对于新功能也就没有这一步了。如果是这个需求会影响以前的代码，则需要将改动部分记录下来，因为项目中的 bug 有很多是改出来的，列出改动点后会让自己更清楚新功能带来的影响，减少很多低级bug。

　　　　　　4）、罗列自测能容：编码完成以后，一定要进行自测试，自测试越仔细，越能提前发现 bug 并修复。如果是测试人员发现了 bug ，然后再提交给你，你这时候再去解决，效率往往会比较低。　　

　　　　　　　　以发送消息为例，自测内容也有很多：

　　　　　　　　a）、正常发送消息

　　　　　　　　b）、未登录的时候点击发送

　　　　　　　　c）、没网络的时候点击发送

　　　　　　　　等等...

 

　　第二、编程中

　　　　1、是重写还是保持不变？

　　　　　　每做一个新需求，都有可能会面临这样的问题：　

　　　　　　　　1）、以前的模块儿写的太烂，很想重新写

　　　　　　　　2）、差不多的需求，以前用了这样的方式实现，这次想换一种方式实现

　　　　　　会考虑以上的问题，证明你是一个想要不断进步的人，但是，在做决定之前最好先考虑以下因素：

　　　　　　　　1）、重写模块，很可能牵一发而动全身，要想清楚改动可能带来的影响，以及解决这些问题需要的时间

　　　　　　　　2）、使用新方案实现需求，新的方案是否已经经过仔细的验证，如果没有，它可能会带来新问题

　　　　2、实现需求Demo先行。

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

　　　　3、借助工具。

　　　　　　1）、代码模板和项目模板

　　　　　　　　我们创建一个视图，控制器，或者一个 Model，可能会有一些固定不变的函数、属性需要被定义或者重写，使用 Xcode 可以创建代码模板，在创建类文件的时候一键生成这些代码，提高效率。

　　　　　　2）、代码片段

　　　　　　　　一般可重用的代码，我们会封装成类或者函数，以便其他地方使用，但有一些代码是不适合封装的，例如：声明一个属性、创建一个线程

　　　　4、适当添加和修改注释

　　　　　　如果像官方的 API 那样，所有地方都添加注释，那工作量就太大了，需要额外的开发时间，如果只是针对一些语义不明、有歧义的代码添加注释，反而会减少开发时间。

　　　　　　例如一个属性：

　　　　　　@property (nonatomic, assign) int64_t createTime;

　　　　　　一看就知道是指创建时间，但它到底是不是时间戳？如果是时间戳，那单位是秒还是毫秒？如果还要打印数据以后才能下结论，就太耗时间了。

加上注释以后，它就一目了然了

　　　　　　/// 创建时间（时间戳 秒）

　　　　　　@property (nonatomic, assign) int64_t createTime;

　　　　　　特别说明，当你的方法实现思路变了，或者功能发生了改变，对应的注释也要一起修改，否则会对以后的维护人员带来很大的困扰。

　　第三、编程完（自测）

　　　　1、先检查后自测：完成一个小功能以后，先检查一下代码，然后再开始自测，因为代码可以告诉你很多信息。

　　　　　　1）、是否有低级错误

　　　　　　2）、是否有难以发现的漏洞

　　　　　　3）、流程是否存在问题

　　　　如果你编码完成以后立即自测，可能会进入被动状态：

　　　　　　1）、这个界面显示不对

　　　　　　2）、这个数据跟预期对不上

　　　　　　3）、有些不该出现的东西出现了

　　　　这时候再反过来去调试代码，一步步修改，会很慢，因为你编译和操作都需要时间，而且有些条件不是很容易模拟，那种情况就更耗时间了。

　　　　2、自测点要全部过一遍

　　　　　　可能你会觉得这很烦，很浪费程序员的时间，但自测过程发现 bug 是最容易修复的，因为这时候代码记忆最清晰，最容易找到问题所在。

　　第四、总结

　　　　理清思路—>开始编码—>检查代码—>代码自测，这就是整个开发的过程。

　　　　其实知道一个技巧，并不会提升效率，只有坚持使用这个技巧，并形成习惯以后，才会真正地提高效率。