软件发布| 专题库| 优优资讯| 苹果专区| 安卓专区| 软件下载| 首页
优优资讯 电脑教程 安卓教程 安卓攻略 苹果教程 苹果攻略 新闻资讯

iOS开发:高效编程技巧

时间:2015-12-11 来源:本站整理 我要评论

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

用户评论

(已有0条评论)
表情
注:您的评论需要经过审核才能显示哦,请文明发言!
还没有评论,快来抢沙发吧!
快速检索
0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z