iOS端开发心得实践

作者: shaneZhang 分类: ios技术 发布时间: 2017-08-17 09:56

About Project

在IT行业总是流传着一个小笑话,一般来说当我们接手一个已有的项目的时候,似乎总是显示乱七八糟的,然后经过我们一番的细调微整之后变得更糟糕,就这样在一波又一波的人手中不断成长着。 程序员的交接工作图 虽然现实情况是这个样子,一个项目拿到手里的时候还是想努力地去改变它,也许也是为了让后面的人少骂几句,所以大家一直在尽自己最大的努力去做好这个事情。

iOS整体项目组织结构

  • 整体代码结构,小MVC和大MVC的区别. 当然了,我看到很多公司在采用大的MVC结构,包括我们刚接手到租车项目的时候。下面我们就一起来看一下大MVC和小MVC结构的各自优劣势。 1>大MVC代码结构之间相对松散一些,脱离了业务模块,但是整体设计结构上却是非常清晰的。随着代码量的不断增加,劣势也就是逐渐凸显出来,找代码各种找不到啊。 2>小MVC一般来说是按照业务模块来组织代码,每个模块争取相对独立,但是因为某些因素也并不能完全独立出来,这就导致了,有些代码是放到这儿也行,放到那儿也行,不知所措啊。——-我个人还是倾向于小MVC这种结构.
  • 代码拆分粒度 粗粒度和细粒度之争、继承与组合之争 之前看到过去的同事在一遍又一遍地写着各种各样的cell,而且每个地方用的都不一样,虽然有一些是很相似的,但是也无法公用。我就在想着,这种地方为什么不用继承呢,把初始的类写的抽象一点,使得更适应后面的变化,这个时候有人就提出来了,坚决不要用继承,你们又怎么看呢?我是更倾向于这种抽象继承策略的,这样可以使得每个类都相对不是那么臃肿。

  • 命名规范的问题 1>类的命名,长 or 短 ? 2>变量的命名,不要用简写不要用简写不要用简写 3>方法的命名,同上 4>单词的使用问题,尽量通俗易懂(文化低,怪我咯?)

  • 注释的争论 太多 or 太少 ??? 有的人一行注释都不写,有的人密密麻麻。 我比较倾向于,只写头文件中类注释 方法注释 变量注释,因为这几个地方涉及到其他类的相互调用和传参数,当然在某些业务场景特别复杂的情况,我可能会每一行代码都会加入注释,以理清自己的思路

  • 业务逻辑的构造 我比较推荐于多个相同或相近的业务模块应当单独抽取拆分,争取整合在一起使用。这样读到这个类,可以了解整个项目中关于这个功能的相关情况。

  • 代码规范的问题 1>像枚举、单例、类模版的写法 2>代码结构的组织 3>括号的对齐方式等

About Version Control

git管理开发之道

About Code decoupling

关于代码解耦:

1>采用Pod+适当代码冗余来做独立模块或功能

2>采用路由的策略来做代码内部解耦

3>合理使用NSNotification

About FRP

在租车iOS端项目中,之前曾经体验过一段这种思想的编程,但是由于人员的流动,导致后面的人没有继续接着这条路探索下去,目前只有几个人还在使用这种方法。我个人认为这个还是非常值得去探索的一个事情。

About Code Quality

关于代码质量:

1>增强工程配置,日常开发中使用静态分析等手段

2>用好Instruments等工具

3>做好CodeReview(相互Reivew Or 一人review)

4>做好持续集成等监测

5>工作流的固化 你一辈子都可能达不到别人的高度,凭什么说别人的方法论没用?

About The Future

向专车的各位童靴们学习。

1>持续抽取基础工具包,基本能达到100个工具或者模块包算是一个相对完善的技术模块累积,高楼万丈也不是一下子就起来的。

2>探索新的开发方法

3>梳理业务流程,规划合理的技术选型方案。

4>合理的技术选型规划还是蛮重要的。如验车单损坏电子方案,各种数据优化方案

本页面支持AMP友好显示:iOS端开发心得实践

如果觉得我的文章对您有用,请随意打赏。如果有其他问题请联系博主QQ(909491009)或者下方留言!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

÷ 4 = 1

This site uses Akismet to reduce spam. Learn how your comment data is processed.