规范（代码的规范）
2.1 认知成本
发现共同抽象和机制可以在很大程度上帮助我们理解复杂系统
2.2 混乱时代
在工作中很多工程师抱怨他们的系统很凌乱，毫无章法可言，即使花费很长时间也很难理清系统的脉络。在评估一个需求时，要在杂乱无章的代码中找好久才能找到相关的需求改点，然而真正需要改动的代码可能只有一行而已，这样的无序在很大程度上是系统缺少代码组织结构造成的。
2.3 代码规范，
代码的格式关系倒代码的可读性，因此需要遵从一定的规范包括缩进,水平对齐,注释格式等。关于代码格式可能会因为语言和个人的偏好而不同，但是一个团队最好选定一种格式，因为一致性可以减少复杂度。
- 空行规范
空行在代码中起到的概念区隔作用，每个空白行都
是一条线索，提示你下一组代码表示的是不同的概念或功能
//弹窗动画类型
typedef NS_ENUM(NSInteger, CMBCWindowAlertType) {
CMBCWindowAlertNone, //无动画
CMBCWindowAlertWithAlpha, //Alpha渐变0~1
CMBCWindowAlertWithScale, //Scale渐变0~1(基于视图中心)
CMBCWindowAlertFromTop, //顶部向下
CMBCWindowAlertFromLeft, //左侧向右
CMBCWindowAlertFromBottom, //底部向上
CMBCWindowAlertFromRight, //右侧向左
CMBCWindowAlertFromTabBar, //tabbar向上
CMBCWindowAlertFromNaviBar, //导航栏向下
};
//弹窗优先级类型
typedef NS_ENUM(NSInteger, CMBCWindowAlertPriorityType) {
CMBCWindowAlertPriorityStart = 0,
CMBCWindowAlertPriorityOne,
CMBCWindowAlertPriorityTwo,
CMBCWindowAlertPriorityThree,
CMBCWindowAlertPriorityEnd //结束标志，可在该选项前面扩展优先级
};
//弹窗位置类型
typedef NS_ENUM(NSInteger, CMBCWindowAlertLocationType) {
CMBCWindowAlertLocationFirst, //第一页，tabbar的第0个VC，如：首页
CMBCWindowAlertLocationSecond, //第二页，tabbar的第1个VC，如：生活圈
CMBCWindowAlertPriorityThird, //第三页，tabbar的第2个VC，如：财富
CMBCWindowAlertPriorityFour, //第四页，tabbar的第3个VC，如：我
CMBCWindowAlertLocationAll, //所有页面，tabbar的所有VC
};
若删掉空格代码的可读性就会弱很多
//弹窗动画类型
typedef NS_ENUM(NSInteger, CMBCWindowAlertType) {
CMBCWindowAlertNone, //无动画
CMBCWindowAlertWithAlpha, //Alpha渐变0~1
CMBCWindowAlertWithScale, //Scale渐变0~1(基于视图中心)
CMBCWindowAlertFromTop, //顶部向下
CMBCWindowAlertFromLeft, //左侧向右
CMBCWindowAlertFromBottom, //底部向上
CMBCWindowAlertFromRight, //右侧向左
CMBCWindowAlertFromTabBar, //tabbar向上
CMBCWindowAlertFromNaviBar, //导航栏向下
};
//弹窗优先级类型
typedef NS_ENUM(NSInteger, CMBCWindowAlertPriorityType) {
CMBCWindowAlertPriorityStart = 0,
CMBCWindowAlertPriorityOne,
CMBCWindowAlertPriorityTwo,
CMBCWindowAlertPriorityThree,
CMBCWindowAlertPriorityEnd //结束标志，可在该选项前面扩展优先级
};
//弹窗位置类型
typedef NS_ENUM(NSInteger, CMBCWindowAlertLocationType) {
CMBCWindowAlertLocationFirst, //第一页，tabbar的第0个VC，如：首页
CMBCWindowAlertLocationSecond, //第二页，tabbar的第1个VC，如：生活圈
CMBCWindowAlertPriorityThird, //第三页，tabbar的第2个VC，如：财富
CMBCWindowAlertPriorityFour, //第四页，tabbar的第3个VC，如：我
CMBCWindowAlertLocationAll, //所有页面，tabbar的所有VC
};
注意！！！！
如果在每一行代码后面都加一个空行，这样空行就失去了意义，其结果是和没有空行一样的。
简单的原则：
将概念相关的代码放在一起，相关性越强，彼此之间的距离应该越短。
- 命名规范
- 类名采用大驼峰形式，既首字母大写的驼峰，例如：SDWebImage YYModel
- 方法名采用小驼峰的形式，既首字母小写，方法名一般为动词，与参数组成动宾结构- (void)cancelAllDownloads
- 常量命名的字母全部大写，单词之间用下划线连接，例如FACE_DEFAULT_OUTPUT_IMAGE_WIDTH
- 枚举类以 typedef NS_ENUM 开头，异常类使用NSException 结尾
2.3 异常规范
1. 异常处理
很多应用系统因为没有统一的异常处理规范，增加了认为的复杂性，具体体现在两个方面。
代码中到处充斥着异常捕获的try/catch的代码，扰乱了代码的结构，把错误的处理与正常的流程混为一谈，严重影响代码的可读性
异常处理不统一，有的场景对外直接抛出异常，有的场景对外直接返回错误码，这种不一致性让服务的调用方摸不着头脑。增加服务的使用成本和沟通成本。
针对以上问题我建议在业务系统中设置两个异常，分别是BizException(业务异常)和SysException(系统异常)，
1. 错误码
错误码并没有统一的约定，错误码管理混乱会给后续的系统维护（特别是在理清系统业务脉络和问题定位上）带来很多麻烦。
错误码非常重要，一定要在系统搭建之初就制定好相应的规范，否则当系统上线后，系统的错误码已经对前端或者外部系统进行透出，在重构的可能性很小。
2.4 架构规范
规范对于架构来说至关重要，从某种意义上来说，架构就是一组约束，遵从了这些约束，才能符合架构的要求：反之架构将失去意义，例如打算采用前后端分离的架构，但又不想遵守前后端分离的约束，允许部分的前端模块代码仍在后端维护，那么这个架构就是去了意义。
架构应遵循相同的分层原则，类似模块化思想和分包机制。
2.5 防止破窗
破窗效应是犯罪心理学中一个著名的理论，
环境中的不良现象如果被放任存在，就会使人仿效，甚至变本加利。
任何一种已经存在的不良现象都在传递着一种信息，会导致不良现象无限扩展，同时必须高度警觉哪些看起来偶然的，个别的，轻微的，“过错”，如果对过错不闻不问，熟视无赌，反应迟钝或纠正不力，就会纵容更多的人“去打烂更多的窗户”，极有可能演变成“千里之堤，溃于蚁穴”的恶果。
在软件工程中，“破窗效应”可谓是屡见不鲜，面对一个混乱的系统和一段杂乱无章的代码，往往会加入更多垃圾的代码，这也彰显了规范和重构的价值。首先我们要有一套规范，并尽量遵守规范，不要做第一打破第一扇窗的人；其次发现有“破窗”，要及时地修复，不要让事情进一步恶化。整洁的代码需要每一个人的精心守护。需要整个团队都具备一些工匠精神。
混乱会造成复杂，有序会减少复杂度。制定规范是为了从无序走向有序，减少认知成本。在软件开发过程中，大到体系结构和应用框架规范。小到代码格式和空行的约定，都在一定程度上影响着复杂程度。
要记住，留给公司一个方便维护，整洁优雅的代码库，是我们技术人员的最高使命，也是我们对公司做出的最大技术贡献。