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管理开发之道

git merge -s recursive -X theirs release-3.5.1  合并release-3.5.1冲突时用release-3.5.1的代码替换master的代码
git merge -s recursive -X ours release-3.5.1  合并release-3.5.1冲突时用master的代码替换release-3.5.1的代码

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>合理的技术选型规划还是蛮重要的。如验车单损坏电子方案，各种数据优化方案