1. 组织类1.1. 每一个接口、类、结构体和枚举均应当拥有其自身的独立源文件1.2. Pascal命名方法命名命名空间1.3. 测试类定义在独立的程序集1.3.1. 不同程序集的测试放在不同程序集1.3.2. 程序集名称的最后附加Tests命名空间1.4. 公司名称、产品名称和缩写词汇无须使用复数形式2. 单一职责原则2.1. （SingleRespon-sibilityPrinciple，SRP）2.2. 一个类应当只具备一种职责2.3. 类的职责就是类所具备的功能3. 从注释生成文档3.1. 源代码文件的顶部都应当包含版权声明3.2. 命名空间、接口、类、枚举、结构体、方法和属性都应当包
1. 组织类1.1. 每一个接口、类、结构体和枚举均应当拥有其自身的独立源文件1.2. Pascal命名方法命名命名空间1.3. 测试类定义在独立的程序集1.3.1. 不同程序集的测试放在不同程序集1.3.2. 程序集名称的最后附加Tests命名空间1.4. 公司名称、产品名称和缩写词汇无须使用复数形式2. 单一职责原则2.1. （SingleRespon-sibilityPrinciple，SRP）2.2. 一个类应当只具备一种职责2.3. 类的职责就是类所具备的功能3. 从注释生成文档3.1. 源代码文件的顶部都应当包含版权声明3.2. 命名空间、接口、类、枚举、结构体、方法和属性都应当包
1. 核心关注点1.1. 开发软件的原因2. 切面关注点2.1. 所有的代码领域都需要处理相关的问题3. 结构化模式3.1. 装饰器模式3.1.1. 可以在现有对象上添加新的功能，而不改变其结构3.2. 代理模式3.2.1. 所提供的对象可以替代客户端使用的实际服务对象4. 使用PostSharp实现AOP4.1. 收费软件4.2. 缓存4.3. 日志4.4. 异常4.5. 安全4.6. 验证4.7. 事务4.8. 资源池4.9. 配置4.10. 检测4.11. 推荐使用Castle5. 异常处理5.1. unchecked模式5.1.1. 改善性能5.1.2. 很多情况下unchecked模
1. 核心关注点1.1. 开发软件的原因2. 切面关注点2.1. 所有的代码领域都需要处理相关的问题3. 结构化模式3.1. 装饰器模式3.1.1. 可以在现有对象上添加新的功能，而不改变其结构3.2. 代理模式3.2.1. 所提供的对象可以替代客户端使用的实际服务对象4. 使用PostSharp实现AOP4.1. 收费软件4.2. 缓存4.3. 日志4.4. 异常4.5. 安全4.6. 验证4.7. 事务4.8. 资源池4.9. 配置4.10. 检测4.11. 推荐使用Castle5. 异常处理5.1. unchecked模式5.1.1. 改善性能5.1.2. 很多情况下unchecked模
1. 高品质的代码1.1. 性能（Performance）1.1.1. 只执行需要的操作，而且执行迅速1.1.2. 不会使系统陷入停顿1.2. 可用性（Availability）1.2.1. 持续在所需的性能水平上保持可用1.2.2. Topic11.3. 安全性（Security）1.3.1. 正确验证输入1.3.2. 防止无效的数据格式或超范围的无效数据1.3.3. 防止恶意攻击代码1.3.4. 身份验证1.3.5. 鉴权操作1.3.6. 具备容错性1.4. 可伸缩性（Scalability）1.4.1. 安全地处理指数级增长的用户数目，而不会令系统停顿1.5. 可维护性（Maintain
1. 高品质的代码1.1. 性能（Performance）1.1.1. 只执行需要的操作，而且执行迅速1.1.2. 不会使系统陷入停顿1.2. 可用性（Availability）1.2.1. 持续在所需的性能水平上保持可用1.2.2. Topic11.3. 安全性（Security）1.3.1. 正确验证输入1.3.2. 防止无效的数据格式或超范围的无效数据1.3.3. 防止恶意攻击代码1.3.4. 身份验证1.3.5. 鉴权操作1.3.6. 具备容错性1.4. 可伸缩性（Scalability）1.4.1. 安全地处理指数级增长的用户数目，而不会令系统停顿1.5. 可维护性（Maintain
1. 应用程序级别代码坏味道1.1. 布尔盲点1.1.1. 由于函数使用布尔值而导致的信息缺失1.1.2. 解决方案是将布尔替换为枚举类型1.2. 组合爆炸1.2.1. 不同的代码使用不同的参数组合来执行同一件事情的产物1.2.2. 解决方案使用泛型1.3. 人为复杂性1.3.1. 简单的架构复杂化1.3.2. 解决方案务必保持软件的简单易懂（KeepItSimple，Stupid，KISS）1.4. 数据泥团1.4.1. 相同的字段同时出现在不同的类和参数列表中时1.4.1.1. 说明系统中缺少类定义1.4.2. 识别并泛化缺失的类可以降低系统的复杂度1.5. 粉饰注释1.5.1. 注释中用
1. 应用程序级别代码坏味道1.1. 布尔盲点1.1.1. 由于函数使用布尔值而导致的信息缺失1.1.2. 解决方案是将布尔替换为枚举类型1.2. 组合爆炸1.2.1. 不同的代码使用不同的参数组合来执行同一件事情的产物1.2.2. 解决方案使用泛型1.3. 人为复杂性1.3.1. 简单的架构复杂化1.3.2. 解决方案务必保持软件的简单易懂（KeepItSimple，Stupid，KISS）1.4. 数据泥团1.4.1. 相同的字段同时出现在不同的类和参数列表中时1.4.1.1. 说明系统中缺少类定义1.4.2. 识别并泛化缺失的类可以降低系统的复杂度1.5. 粉饰注释1.5.1. 注释中用
作者 | 银大伟现如今，适时利用云计算提供的资源弹性伸缩能力以及托管服务已成为行业共识，是否采纳和使用云对于企业而言已不再是选答题而是必答题。能否做到业务上云，即企业能否真正有效地利用云及其生态所提供的新技术和平台来赋能业务、加速数字化转型、提升企业的竞争力，对很多企业来说依然是一个巨大的挑战。据观察，许多企业的业务上云旅程并不顺利，甚至可以说十分艰难，特别是在上云的系统规模比较大（系统数量在几百甚至上千）和涉及的业务线比较多的时候。挑战不仅仅来自技术层面，也来自原有的组织结构、团队能力和研发体系。另外，还有一些企业把云迁移作为自身业务上云的目标，这显然是不合理的，因为这很容易导致把业务上云
作者 | 银大伟现如今，适时利用云计算提供的资源弹性伸缩能力以及托管服务已成为行业共识，是否采纳和使用云对于企业而言已不再是选答题而是必答题。能否做到业务上云，即企业能否真正有效地利用云及其生态所提供的新技术和平台来赋能业务、加速数字化转型、提升企业的竞争力，对很多企业来说依然是一个巨大的挑战。据观察，许多企业的业务上云旅程并不顺利，甚至可以说十分艰难，特别是在上云的系统规模比较大（系统数量在几百甚至上千）和涉及的业务线比较多的时候。挑战不仅仅来自技术层面，也来自原有的组织结构、团队能力和研发体系。另外，还有一些企业把云迁移作为自身业务上云的目标，这显然是不合理的，因为这很容易导致把业务上云
