iOS App 开发的那些事儿 1：如何创建合适的规范

《iOS App 开发的那些事儿》系列文章从更宏观的角度出发，不单单局限于具体某个功能、界面的实现，而是结合网易云信 iOS 端研发负责人多年的经验，从如何优化现有代码的角度出发，深度分析如何创造出 iOS App 开发中比较合适的规范和框架。

将代码规范合理分级

你们都理解软件开发须要合适的规范：代码规范，程序规范，流程规范等等，以此来减小意外的出现：最少惊讶原则。但在实际执行中却会碰到各类状况，其中最大的问题是：怎么鉴别哪些规范是须要强制执行，哪些规范是推荐执行。
规范的强制执行带来的是代码的可读性提高和二义性减小，而坏处也是显而易见的：对于大部分有想法的程序员而言这种规定太死板，容易引发抵触心理，产生不安定因素。这种状况常见于各类标准的外包公司。
而若是大部分的规范设定为推荐执行，在没有良好的引导下，规范容易被忽视。 网上有不少关于ObjC的代码规范，好比苹果自家的规范和《Google Objective-C Style Guide》等。这些规范通常只有两种分级:推荐和不推荐。而我更推荐把代码规范分红五个等级：强制要求，强烈推荐(但不强制)，良好，可接受和不可接受。
如下仅举部分例子加以说明。

符合苹果规范的命名方式

• 类名开头大写，方法和变量名以驼峰法命名。强烈要求，这没有什么好说的，苹果系统类库和绝大多数的第三方开源库都是如此。但在部分苹果的 sample 中也看到过用m作前缀表示类成员变量的写法，这些都是属于遗产代码的问题，仍旧是可接受范围，可是本身代码内部使用相似匈牙利的命名法就是不可接受。
• 类名使用至少三个字符作前缀，内部方法使用两个下划线作前缀。强烈推荐。上面的作法能够最大程度避免和系统类库发生重名的状况：由于苹果宣称保留全部两位字符前缀的使用权，同时其内部方法命名以一个下划线作前缀。
• 不管使用 K&R Style 仍是 Allman Style 都是可接受的范围，可是强烈推荐在一个文件内保持一种形式。
• 在保证代码可读性的基础上保持代码的简短和统一性：小类，小方法，统一的函数返回。小类，小方法能够保证他人阅读时更方便地关注类逻辑，而不是具体细节，而统一的函数返回能够减小意外错误和下降错误排查的难度。而保证代码的简短和不罗嗦也是很重要一点，常常会看到以下代码： if (count > 1) { return YES; } { return NO; }，真心没法直视。

良好的代码/工程结构

• 为整个工程建立 workspace。
• 按照权责分门别类存放资源文件：每种类型的资源存放于独立的目录下：图片，声音，配置文件等等。而图片又能够按照类型分别存放在不一样的子目录下：全局类型，背景图，logo，登陆等等。
• 合理的代码结构。

Core：工程内一些通用的机制实现类：统一的任务管理，模块管理，服务管理。
General：公用类和方法，包括工程内ViewController,UITableViewCell基类(Base)，公用Category(Category)：公用UI组件(CustomUI)，公用辅助方法(Helper)和宏定义(Marco)。
Model：公用数据模型
Sections：不一样程序单元。如登陆，设置等等。其下又能够按照功能分红不一样的子目录：当前单元使用的自定义UI组件，管理类，数据模型和ViewController等等。
Vendors：第三方库。

《iOS App开发的那些事儿》第二篇文章将会向你们介绍什么是合适的框架，如何搭建合适的框架，欢迎你们积极发表本身的见解，与咱们共同讨论。

---

随着即时通信以及音频处理和压缩技术的不断发展，效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现，若是你有好的技术或者分享，欢迎关注网易云信官方博客和 GitHub：

关注更多技术干货内容： 网易云信博客
欢迎关注 网易云信 GitHub
欢迎关注 网易云信官网