习惯影响一个人做事的方式，直接影响效率。我经常在项目完成后总结自己。我哪些地方做得好，哪些地方做得不好？然后记录一些好的过程，在编程中复用。那些我能坚持的流程已经成为我的编程习惯，这些好习惯让我的编程变得高效！一、轻文件先什么是轻文件？其实轻文档是指不需要按照标准的软件工程知识去写需求分析、架构设计、模块设计、流程图时序图等文档，而是用一种相对自由的方式去做自己该做的事情，并且去做吧。清楚地描述事物步骤的文档。这样的文档不需要限制格式，你甚至可以手写在自己的笔记本上，只要你能看懂，在开发过程中随时可以查看。一、为什么要写文档刚开始工作的时候，总是一接到任务就开始写代码，但是遇到了很多问题，例如：①.需求本身就有问题，代码写到一半才发现②。需求没有表达清楚，发现了才沟通。原来是时间不够，或者是和之前的代码有冲突。如果在开发前把需求分解，把问题沟通清楚，把要做的事情一一列出，就可以大大避免这些问题。2.文件中要写什么①。开始准备工作前需要准备什么？例如，要制作一个发送消息的接口，需要做以下准备工作：接口协议B.测试环境C.提前做好测试账户准备工作，往往会加快效率。之所以记录这些内容，是为了在开发过程中快速检索。如果等到开始开发后再查看聊天记录，或者询问相关人员，会比较慢。②.列出需要做的小功能点。比如做一个发送消息的接口，有很多小功能点：发送接口B.发送数据接口c．文字字数限制仔细想想，可能会出现以下问题：a．是否需要登录？如果没有登录，是否要引导登录？b.发送失败如何处理？C。字数超限怎么互动？d.如果用户重复发送相同的文本，是否要过滤？e.数据接口错误码如何处理？当你把这些小功能记录下来，和产品经理沟通清楚后，你的开发周期就可以初步评估了，这时候你就已经搞清楚了这个需求有多少个小功能，模块怎么划分，内部流程怎么搭建.对于一些流程比较复杂的功能，可以画流程图辅助理解③。记录此需求的变化。如果这是新需求，与之前版本无关，可以忽略这部分。如果这个需求会影响到之前的版本代码，需要记录改动的部分，因为项目中的很多bug都是改动过的。列出改动点后，你会更清楚新功能的影响，减少了很多低级bug，比如新增了一个发送图片的功能，会影响聊天窗口和键盘的显示，而这些必须记录更改。一来可以辅助思考是否有遗漏的小功能点，二来需要覆盖自测时聊天窗口的显示和键盘的切换。④.列出自测内容编码后，必须进行自测。自检越仔细，就越能提前发现和修复bug。如果测试人员发现了bug，然后提交给你，你这时候去解决，效率往往会比较低。以发送消息为例，自检内容有很多：a．正常发送消息B.未登录时点击发送c．字符数超过限制d．无网络时发送e．...2。开始编码1.重写还是保持不变每次你提出新的需求，你可能会面临这样的问题：①．之前已经通过这种方式实现了需求。这一次，如果你想换一种方式去实现，你会考虑以上的问题，证明你是一个想要精益求精的人。但是，在做决定前最好考虑以下因素：①．重写模块很可能牵一发而动全身。有必要了解变更可能带来的影响以及解决这些问题所需的时间。②.使用新方案实现需求，新方案是否经过仔细验证，如果没有，可能会带来新的问题。事实上，保持不变有一些好处：①。你可以比以前做得更快，因为你熟悉它。②.不会出现新的问题。基本上，答案已经有了，但维持现状并不意味着放弃追求。您可以利用业余时间来证明您的计划。当稳定可行的时候，可以随时重写。2、实现需求，Demo是先实现一个需求最快的方式，因为运行速度快，可以随意修改，代码量小。如果执行过程中出现问题，很容易定位到原因。先创建一个demo，然后移植需要的资源，再将功能移植到项目中，这样可以节省大量的开发时间3.借助工具①。代码模板（FileTemplate）我们创建一个view，controller，或者一个Model，可能会有一些固定的函数和属性需要定义或者重写，使用Xcode创建代码模板，在创建类的时候一键生成这些代码文件以提高效率。②.代码片段（CodeSnippet）一般可重用的代码，我们会将其封装成一个类或函数以供其他地方使用，但有些代码不适合封装，例如：a．声明属性B.Createathreadlike对于这种代码，我会做一个codesnippet，然后通过Xcode的CodeSnippet自动补充功能快速完成。代码片段示例：这里写个图片描述，输入@OperateThread直接完成创建操作队列的代码，大Amplitude减少编码时间。③.自动评论工具（VVDocumenter）是一个可以一键创建评论模板的工具，减少写评论的时间4.适当添加评论如果像官方API一样到处添加评论，工作量会太大，需要额外开发时间。如果只对一些语义不明确、有歧义的代码添加注释，会减少开发时间。例如一个属性：@property(nonatomic,assign)int64_tcreateTime；一看就知道指的是创建时间，但是是时间戳吗？如果是时间戳，是秒还是毫秒？如果非得把数据打印出来才能得出结论，那就太费时间了。添加注释后，一目了然///创建时间（时间戳秒）@property(nonatomic,assign)int64_tcreateTime;三、自测1.先检查再自测完成一个小功能后，先检查代码，然后开始自测，因为代码可以告诉你很多信息：①．是否存在低级错误②．是否存在难以发现的漏洞③。该界面显示错误②。数据与预期不符③。当一些不该出现的东西出现在这个时候，再去调试代码，一步步修改，会很慢，因为你编译和运行都需要时间。而有些情况是不容易模拟的，那种情况会需要更多的时间。2.你可能会觉得把所有的自测点都过一遍很烦人，浪费程序员的时间，但是自测过程中发现的bug是最容易修复的，因为此时代码记忆最清晰，最容易发现问题。4.总结先用文档理清思路，然后开始编码。编码后，检查代码并测试自己。这是我的编程习惯，我到现在还在沿用。事实上，知道一种技术并不会提高效率。只有坚持使用这个技巧并养成习惯，才能真正提高效率。
