方法论汇总

方法论汇总

内容大部分整理自Pdai的技术博客，将方法论部分整合起来

一：开发理论篇

1：软件开发原则-SOLID

SOLID 是面向对象设计和编程的五个基本原则的缩写，由 Robert C. Martin (Uncle Bob) 提出

它们是编写可维护、可扩展软件的重要指导原则。

• SRP 确保每个类职责单一
• OCP 通过抽象使系统易于扩展
• LSP 保证继承关系的正确性
• ISP 避免接口污染
• DIP 降低模块间的耦合度

1.1：单一职责原则-SRP

一个类最好只做一件事，只有一个引起它的变化。单一职责原则可以看做是低耦合，高内聚在面向对象原则的引申

将职责定义为引起变化的原因，以提高内聚性减少引起变化的原因。

核心思想如下：每个类应该专注于做一件事情 & 每个类应该只有一个改变的理由 & 将不同的职责分离到不同的类中

原则的分析

• 一个类(或者大到模块，小到方法)承担的职责越多，它被复用的可能性越小，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。
• 类的职责主要包括两个方面: 数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。
• 单一职责原则是实现高内聚、低耦合的指导方针，在很多代码重构手法中都能找到它的存在，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

// 违反SRP
class User {void login() { /*...*/ }void sendEmail() { /*...*/ }void saveToDB() { /*...*/ }
}// 遵循SRP
class User { /* 只含用户数据 */ }
class Auth { void login(User u) { /*...*/ } }
class EmailService { void sendEmail(User u) { /*...*/ } }
class UserRepository { void save(User u) { /*...*/ } }

1.2：开放封闭原则-OCP

一个软件实体(如类、模块和函数)应该对扩展开放，对修改关闭

一个好的软件系统就是在不修改源代码的情况下，可以扩展你的功能，而实现开闭原则的关键就是抽象化

原则的分析

• 当软件实体因需求要变化时，尽量通过扩展已有软件实体，可以提供新的行为，以满足对软件的新的需求，而不是修改已有的代码，使变化中的软件有一定的适应性和灵活性。已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。
• 实现开闭原则的关键就是抽象化：即要预知可能变化的需求，又预见所有可能已知的扩展。所以在这里"抽象化"是关键!
• 可变性的封闭原则：找到系统的可变因素,将它封装起来，这是对"开-闭"原则最好的实现。

// 违反OCP
class Rectangle {double width;double height;
}class AreaCalculator {double calculate(Object shape) {if (shape instanceof Rectangle) {// 计算矩形面积}// 添加新形状需要修改此类}
}// 遵循OCP
interface Shape {double area();
}class Rectangle implements Shape {double area() { /*...*/ }
}class Circle implements Shape {double area() { /*...*/ }
}

1.3：里氏替换原则-LSP

子类型必须能够替换它们的基类型而不引起程序错误

子类不应该破坏父类的行为 & 子类可以扩展父类功能，但不能改变原有功能 & 前置条件不能强化，后置条件不能弱化

原则的分析

• 讲的是基类和子类的关系，只有这种关系存在时，里氏代换原则才存在。正方形是长方形是理解里氏代换原则的经典例子。
• 里氏代换原则可以通俗表述为: 在软件中如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类的话，那么它不一定能够使用基类。
• 里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

// 违反LSP
class Bird {void fly() { /*...*/ }
}class Penguin extends Bird {// 企鹅不会飞，违反LSPvoid fly() { throw new UnsupportedOperationException(); }
}// 遵循LSP
class Bird { /*...*/ }class FlyingBird extends Bird {void fly() { /*...*/ }
}class Penguin extends Bird { /*...*/ }

1.4：接口隔离法则-ISP

客户端不应该依赖那些它不需要的接口。

另一种定义方法: 一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。

⚠️ 在该定义中的接口指的是所定义的方法。例如外面调用某个类的public方法。这个方法对外就是接口。

原则分析

• 使用多个专门的接口，而不使用单一的总接口。每一个接口应该承担一种相对独立的角色
  • 一个接口就只代表一个角色，每个角色都有它特定的一个接口，此时这个原则可以叫做“角色隔离原则”。
  • 应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
• 使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好。
• 可以在进行系统设计时采用定制服务的方式，即为不同的客户端提供宽窄不同的接口，只提供用户需要的行为，而隐藏用户不需要的行为。

// 违反ISP
interface Worker {void work();void eat();
}class Human implements Worker {// 必须实现所有方法
}class Robot implements Worker {void eat() { /* 机器人不需要吃饭 */ }
}// 遵循ISP
interface Workable {void work();
}interface Eatable {void eat();
}class Human implements Workable, Eatable { /*...*/ }
class Robot implements Workable { /*...*/ }

1.5：依赖倒置原则-DIP

高层模块不应该依赖低层模块，两者都应该依赖抽象 & 抽象不应该依赖细节，细节应该依赖抽象

赖倒置原则要求客户端依赖于抽象耦合。原则表述:

1)抽象不应当依赖于细节；细节应当依赖于抽象；

2)要针对接口编程，不针对实现编程。

原则分析

• 如果说开闭原则是面向对象设计的目标,依赖倒转原则是到达面向设计"开闭"原则的手段…如果要达到最好的"开闭"原则,就要尽量的遵守依赖倒转原则. 可以说依赖倒转原则是对"抽象化"的最好规范! 我个人感觉,依赖倒转原则也是里氏代换原则的补充…你理解了里氏代换原则,再来理解依赖倒转原则应该是很容易的。
• 依赖倒转原则的常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中。
• 类之间的耦合: 零耦合关系，具体耦合关系，抽象耦合关系。依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键。

// 违反DIP
class LightBulb {void turnOn() { /*...*/ }
}class Switch {private LightBulb bulb;void operate() {bulb.turnOn();}
}// 遵循DIP
interface Switchable {void turnOn();void turnOff();
}class LightBulb implements Switchable { /*...*/ }class Switch {private Switchable device;Switch(Switchable device) {this.device = device;}void operate() {device.turnOn();}
}

1.6：总结

SOLID 原则不是僵化的规则，而是指导我们编写更好代码的经验总结。在实际应用中需要权衡和灵活运用：

1. 平衡原则与实践：不要为了原则而过度设计
2. 渐进式改进：可以在重构阶段逐步应用这些原则
3. 结合设计模式：许多设计模式都是这些原则的具体体现
4. 考虑项目规模：小型项目可能不需要严格遵循所有原则

一般在项目中都结合起来用：

// 定义抽象
interface PaymentProcessor {void process(Payment payment);
}// 具体实现
class CreditCardProcessor implements PaymentProcessor {public void process(Payment payment) { /*...*/ }
}class PayPalProcessor implements PaymentProcessor {public void process(Payment payment) { /*...*/ }
}// 高层模块
class OrderService {private PaymentProcessor processor;// 依赖注入OrderService(PaymentProcessor processor) {this.processor = processor;}void checkout(Order order) {processor.process(order.getPayment());}
}

2：其他设计原则

2.1：合成/聚合复用原则-CARP

• 合成(组合): 表示一个整体与部分的关系，指一个依托整体而存在的关系(整体与部分不可以分开)；比如眼睛和嘴对于头来说就是组合关系，没有了头就没有眼睛和嘴，它们是不可分割的。在UML中，组合关系用带实心菱形的直线表示。
• 聚合:聚合是比合成关系的一种更强的依赖关系,也表示整体与部分的关系(整体与部分可以分开)；比如螺丝和汽车玩具的关系，螺丝脱离玩具依然可以用在其它设备之上。在UML中，聚合关系用带空心菱形的直线表示。

尽量使用对象组合，而不是继承来达到复用的目的

就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。

简而言之，要尽量使用合成/聚合，尽量不要使用继承。

此原则和里氏代换原则氏相辅相成的,两者都是具体实现"开-闭"原则的规范。违反这一原则，就无法实现"开-闭"原则。

2.2：迪米特法则-LoD

又叫最少知识原则(Least Knowledge Principle或简写为LKP)几种形式定义:

• 不要和“陌生人”说话。英文定义为: Don’t talk to strangers.
• 只与你的直接朋友通信。英文定义为: Talk only to your immediate friends.
• 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

简单地说，也就是，一个对象应当对其它对象有尽可能少的了解。

一个类应该对自己需要耦合或调用的类知道得最少，你(被耦合或调用的类)的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心。

朋友类

在迪米特法则中，对于一个对象，其朋友包括以下几类:

1. 当前对象本身(this)；
2. 以参数形式传入到当前对象方法中的对象；
3. 当前对象的成员对象；
4. 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
5. 当前对象所创建的对象。

任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。

狭义的迪米特法则和广义的迪米特法则

在狭义的迪米特法则中，如果两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

狭义的迪米特法则: 可以降低类之间的耦合，但是会在系统中增加大量的小方法并散落在系统的各个角落，它可以使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联，但是也会造成系统的不同模块之间的通信效率降低，使得系统的不同模块之间不容易协调。

广义的迪米特法则: 指对对象之间的信息流量、流向以及信息的影响的控制，主要是对信息隐藏的控制。信息的隐藏可以使各个子系统之间脱耦，从而允许它们独立地被开发、优化、使用和修改，同时可以促进软件的复用，由于每一个模块都不依赖于其他模块而存在，因此每一个模块都可以独立地在其他的地方使用。一个系统的规模越大，信息的隐藏就越重要，而信息隐藏的重要性也就越明显。

迪米特法则的主要用途: 在于控制信息的过载。

• 在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；
• 在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；
• 在类的设计上，只要有可能，一个类型应当设计成不变类；
• 在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

3：分布式理论CAP & BASE

详细见我这个文章

4：分布式事务ACID

详情见我的这个文章

5：康威定律

设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构 -> 组织形式等同于系统设计

5.1：第一定律

组织沟通方式会通过系统设计表达出来 - 人是复杂的社会动物

组织的沟通和系统设计之间的紧密联系，在很多别的领域有类似的阐述。

对于复杂的系统，聊设计就离不开聊人与人的沟通，解决好人与人的沟通问题，才能有一个好的系统设计。

《人月神话》中写到：沟通成本 = n(n-1)/2，沟通成本随着项目或者组织的人员增加呈指数级增长。

而沟通的问题，会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。

5.2：第二定律

时间再多一件事情也不可能做得完美，但总有时间做完一件事情 - 一口气吃不成胖子，先搞定能搞定的

系统越做越复杂，功能越来越多，外部市场的竞争越来越剧烈，投资人的期待越来越高。

但人的智力是有上限的，即使再牛逼的人，融到钱再多也不一定招到足够多合适的人。

对于一个巨复杂的系统，我们永远无法考虑周全。而敏捷开发专家Eric认为，这个时候最好的解决办法竟然是——“破罐子破摔”。

其实我们在日常开发中也经常碰到。产品经理的需求太复杂了？适当忽略一些细节，先抓主线。产品经理的需求太多了？放弃一些功能。

据说Eric被一家航空公司请去做安全咨询顾问，复杂保证飞机飞行系统的稳定性和安全性。Eric认为做到安全有两种方式：

• 常规的安全指的是尽可能多的发现并消除错误的部分，达到绝对安全，这是理想。
• 另一种则是弹性安全，即使发生错误，只要及时恢复，也能正常工作，这是现实。

这便是持续集成和敏捷开发！！！

同理：对于一个分布式系统，我们几乎永远不可能找到并修复所有的bug，单元测试覆盖1000%也没有用，错误流淌在分布式系统的血液里。解决方法不是消灭这些问题，而是容忍这些问题，在问题发生时，能自动修复，微服务组成的系统，每一个微服务都可能挂掉，这是常态，我们只要有足够的冗余和备份即可。即所谓的弹性设计或者叫高可用设计。

5.3：第三定律

线型系统和线型组织架构间潜在的异质同态特性 -> 种瓜得瓜，做独立自治的子系统减少沟通成本

这是第一定律组织和设计间内在关系的一个具体应用。更直白的说，你想要什么样的系统，就搭建什么样的团队

• 如果你的团队分成前端团队，java后台开发团队，DBA团队，运维团队，你的系统就会长成下面的样子：

• 如果你的系统按照业务边界划分的，大家按照一个业务目标去把自己的模块做成小系统，小产品的话，你的大系统就会成长成下面的样子，即微服务的架构

微服务的团队间应该是 inter-operate, not integrate 。

inter-operate 是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本也就能减低

5.4：第四定律

大的系统组织总是比小系统更倾向于分解 -> 合久必分，分久必合

当我们面对复杂系统时，又往往只能通过增加人力来解决。这时，我们的组织一般是如何解决这个沟通问题的呢？分而治之。

看看自己的公司的组织，是不是一个一线经理一般都是管理15个人以下的？二线经理再管理更少的一线？三线再管理更少的…

所以，一个大的组织因为沟通成本/管理问题，总为被拆分成一个个小团队。

创业的想法太好了，反正风投钱多，多招点程序猿，人多管不过来啊，找几个经理帮我管，我管经理

最后，康威定律告诉我们组织沟通的方式会在系统设计上有所表达，每个经理都被赋予一定的职责去做大系统的某一小部分，他们和大系统便有了沟通的边界，所以大的系统也会因此被拆分成一个个小团队负责的小系统（微服务是一种好的模式）

5.5：对微服务的指导和实践

（1）人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来打成对沟通效率的管理

（2）组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计

（3）如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更加高效。

（4）复杂得系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的

带来的实践的建议(非常重要)

• 我们要用一切手段提升沟通效率，比如slack，github，wiki。能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题
• 通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的
• 你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮
• 做小而美的团队，人多会带来沟通的成本，让效率下降。

二：开源协议

1：软件开源协议

大部分人都希望作品能够被多数人分享查阅。这样不仅提高自己业界的知名度，同时也方便了需要的人为开源做出了贡献。但是代码一旦被贴出来，任何人都可以看到并获取，之后发生的事情你就无法控制了。所以为了公开分享你的代码，同时又让你对代码保留一定权利，在作品中声明一个许可协议是非常有必要的。有协议和没声明协议的裸代码是有非常重要区别的，一般作品当中没声明协议的默认为Copy right的，也就是版权保留。此种情况表明他人没有任何授权，不得复制分发修改使用等等。有了协议的声明，在未来你的维权上面会方便很多，让你的作品在分享的同时保留了自身的一些权利。

License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的

软件协议可分为开源和商业

• 对于商业协议，或者叫法律声明、许可协议，每个软件会有自己的一套行文，由软件作者或专门律师撰写。因为涉及到以后侵权打官司这种事情，这种商业条款的行文是非常严谨而讲究的，读起来很晦涩难懂。
• 对于开源协议，要知道开源不等于免费，也不等于没有约束。虽然相对商业协议要更加简明，但对于很多人来说还是像在看天书一样。

1.1：Apache许可协议

Apache许可证(Apache License)，是一个在Apache软件基金会发布的自由软件许可证，最初为Apache http服务器而撰写。

Apache许可证要求被授权者保留版权和放弃权利的申明，但它不是一个反版权的许可证。

此许可证最新版本为“版本2”，于2004年1月发布。 Apache许可证在Apache社区内外被广泛使用。

Apache基金会下属所有项目都使用Apache许可证，许多非Apache基金会项目也使用了Apache许可证: 据统计，截至2008年4月，在sourceforge上有超过3000个项目使用了Apache许可证。

下面是关于 Apache 许可协议所允许的事项的详细说明:

• 权利永恒。 一旦被授权，权利永久不失。
• 权利无疆界。 在一个国家里被授权，形同于在所有国家被授权。例如，你在美国，但许可权最初在印度被授予，你同样可以使用这个被授权的程序。
• 授权无需付费和支付酬劳。 你既不需要在使用之前支付任何的费用，也无需在每次使用时支付任何的费用，或者其它类似情况。
• 权利不排他。 使用这种许可协议下的软件时，不妨碍你使用其它软件。
• 权利不可变更。 权利一旦授予，不可剥夺。也就是说，你在使用这个软件的过程中，你无需担心这种情况: 当你开发出了令人羡慕的基于这种授权软件的衍生产品时，有人突然跳出来对你说，抱歉，你将不再被允许使用这个程序。(在这个协议里有个条款声明: 如果你控告别人在这个许可协议下的产品有侵犯专利的行为，那你的授权将会自动终止，但这只是适用于有专利权的作品。只要你不搞有专利作品的诉讼，你永远无需担心这种问题。)
• 对再分发的作品还有个特殊要求，总的就是说要给予这些程序的作者和许可协议的维护者适当的名誉。

1.2：MIT许可协议

MIT 协议应该是在流行的开源协议中最简短的、使用最广泛的一种协议。它的条款非常的宽松，而且跟其它协议相比更自由。

MIT 协议是目前最少限制的协议。它基本上就是任何人可以对这个协议下的软件的做任何的事情，只要你能认可这个协议。

这种协议最基本的条款如下：

• 你可以随意使用，复制，修改这个软件。没有人能够阻止你在任何工程里使用它，你可以复制任意次数、以任何形式，或按你的愿望修改它。
• 你可以向外免费发放，或出售。你可以随意的分发它，没有任何限制。
• 唯一的限制是你必须接受协议条款。

1.3：BSD许可协议

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”，可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件:

• 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
• 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
• 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
• BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对 商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发

2：知识共享许可协议文本

2.1：by-nc-nd

署名－非商业使用-禁止演绎

允许重新传播，是六种主要许可协议中限制最为严格的。

这类许可协议通常被称为“免费广告”许可，因为他人只要注明您的姓名并与您建立链接，就下载并与他人共享您的作品，但是他们不能对作品做出任何形式的修改或者进行商业性使用

2.2：by-nc-sa

署名-非商业性使用-相同方式共享

只要他人注明您的姓名并在以您的作品为基础创作的新作品上适用同一类型的许可协议，该他人就可基于非商业目的对您的作品重新编排、节选或者以您的作品为基础进行创作。

基于您的作品创作的所有新作品都要适用同一类型的许可协议，因此适用该项协议，则对任何以您的原作为基础创作的演绎作品自然同样都不得进行商业性使用

2.3：by-nc

署名-非商业性使用

允许他人基于非商业目的对您的作品重新编排、节选或者以您的作品为基础进行创作。

尽管他们的新作品必须注明您的姓名并不得进行商业性使用，但是他们无需在以您的原作为基础创作的演绎作品上适用相同类型的许可条款

2.4：by-nd

署名-禁止演绎

只要他人完整使用您的作品，不改变您的作品并保留您的署名，该他人就可基于商业或者非商业目的，对您的作品进行再传播

2.5：by-sa

署名-相同方式共享

只要他人在其基于您的作品创作的新作品上注明您的姓名并在新作品上适用相同类型的许可协议，该他认就可基于商业或非商业目的对您的作品重 新编排、节选或者以您的作品为基础进行创作。

该项许可协议与开放源代码软件许可协议相类似。

以您的作品为基础创作的所有新作品都要适用相同类型的许可协 议，因此对所有以您的原作为基础创作的演绎作品都可以进行商业性使用

2.6：by

署名

只要他人在您的原著上标明您的姓名，该他人就可以基于商业目的发行、重新编排、节选您的作品。

就他人对您的作品利用程度而言，该项许可协议是我们提供的最为宽松的许可协议

3：国内开源协议

这里主要介绍下木兰系列许可证 - 国内首个

木兰开源许可证第一个版本于 2019年8月5日发布，第二版本于 2020年1月发布。

2020年 2 月 14 日，开源促进会（OSI，Open Source Initiative）批准了来自中国的木兰开源许可证第二版（MulanPSL v2），木兰许可正式成为一个国际化开源软件许可证（或称“协议”）。这意味着中国现在拥有了具有国际通用性、可被任一国际开源基金会或开源社区支持采用，并为任一开源项目提供服务的开源许可证

目前木兰许可证族已研制发布了三个许可证：木兰宽松许可证（MulanPSL v1；MulanPSL v2）、木兰公共许可证（MulanPubL v1；MulanPubL v2）、木兰-白玉兰开放数据许可协议（MBODL v1），分别面向开源软件宽松型、强著作权型以及开放数据集使用等三类不同的开源应用需求。同时木兰开放作品许可证（Mulan Open Works License, Mulan OWL）处于待发布状态，后续可能会推出更多的协议来满足特定的使用场景。

三：代码风格和规范

1：阿里巴巴开发手册

内容在阿里云

2：Google代码风格

内容在github

四：设计模式

设计模式系列文章在我的专栏

或者可以看一些网站

五：开发流程

1：传统模式的开发

1.1：软件生命周期

软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

过程模型（Process Models） 意图解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动（activities）有效地组织了起来，他们之间的线性（linear）、迭代（iterative）、演进（evolutionary）和平行（parallel）关系会产生不同的模型：

• 常见的过程模型包括：瀑布模型、原型模型、增量模型、螺旋模型等。
• (结合软件测试在不同阶段的，又演化出侧重测试的软件测试模型，包括 V 模型、W 模型、H 模型、X 模型等)

1.2：常见模型-瀑布模型

1970 年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到 80 年代早期，它一直是唯一被广泛采用的软件开发模型

瀑布模型将软件生命周期划分为 制定计划、需求分析、软件设计、程序编写、软件测试和运行维护 等六个基本活动，并且规定了它们 自上而下、相互衔接的固定次序 ，如同瀑布流水，逐级下落。

其 严格强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。

所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。

优点：

• 让软件开发过程有序可控，为项目提供了按阶段划分的检查点。瀑布模型的每个阶段都有明确的任务，每个阶段都有明确的交付产物，都有相应的里程碑。这些让整个过程更可控，而且能及早发现问题
• 当前一阶段完成后，您只需要去关注后续阶段
• 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
• 让分工协作变成可能。瀑布模型的六个阶段，也让软件开发产生相应的基础分工：项目经理、产品经理、架构师、软件工程师、测试工程师、运维工程师。
• 质量有保障。瀑布模型每个阶段都需要交付相应的文档，而文档的撰写和评审，可以帮助在动手之前把问题沟通清楚，想清楚。瀑布模型在编码结束后，会有严密的测试，只有测试验收通过后，才能上线发布，这些措施都让软件的质量更有保障。

缺点：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
• 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
• 没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。
• 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
• 瀑布模型的突出缺点是不适应用户需求的变化。
• 瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。

虽然现在瀑布模型已经不是最主流的开发模式。但是不管什么软件项目，不管采用什么开发模式，有四种活动是必不可少的，那就是需求、设计、编码和测试。而这四项活动，都是起源自瀑布模型，也是瀑布模型中核心的部分。 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。

1.3：常见模型-原型模型

原型模型是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的。快速原型是利用原型辅助软件开发的一种新思想。 经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。

优点

• 原型系统已经通过与用户交互而得到验证，克服瀑布模型的缺点，据此产生的规格说明可以正确地描述用户的需求。因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。
• 开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎么不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。

缺点

• 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下，因此不适合大型系统的开发（适合开发小型的、灵活性高的系统）。
• 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新
• 所选用的原型（开发技术和工具）不一定符合主流的发展
• 快速原型模型是不带反馈环的，软件产品的开发基本上是按线性顺序进行的。

现在很多互联网企业提供了各式各样的原型设计工具，例如：Mockplus、Balsamiq、Axure 等

1.4：常见模型-螺旋模型

螺旋模型兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。

同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。

螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。

使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。

这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审 4 个阶段，由这 4 个阶段进行迭代。

软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:

优点

• 通过原型的创建，使软件开发在每个迭代的最初明确方向；
• 通过风险分析，最大程度地降低软件彻底失败造成损失的可能性；
• 在每个迭代阶段植入软件测试，使每个阶段的质量得到保证；
• 整体过程具备很高的灵活性，在开发过程的任何阶段自由应对变化；
• 每个迭代阶段累计开发成本，使支出状况容易掌握；
• 通过对用户反馈的采集，与用户沟通，以保证用户需求的最大实现；

缺点

• 过分依赖风险分析经验与技术，一旦在风险分析过程中出现偏差将造成重大损失；
• 过于灵活的开发过程不利于已经签署合同的客户与开发者之间的协调；
• 由于只适用大型软件，过大的风险管理支出会影响客户的最终收益；

螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。

1.5：常见模型-增量模型

增量模型（Incremental Model）融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。

产品被分解为多个组件，每个组件都是单独设计和构建的。各个构件完成后逐渐并入已有的软件体系结构中。

当使用增量模型时，第 1 个增量往往是核心的产品，即第 1 个增量实现了基本的需求，但很多补充的特征还没有发布。

客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

在增量模型中，每个迭代阶段都得到开发，因此每个阶段都将经历软件开发生命周期的要求、设计、编码，最后是测试模块。每个阶段开发的功能都将添加到以前开发的功能上，在软件完全开发之前，该功能将重复。在每个增量阶段，都会进行审查，根据审查，下一阶段的决定将作出。

增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。

增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

增量模型的特征：

• 系统被分解成许多小型开发项目。
• 部分系统是为了生成最终系统而构建的。
• 首先满足最高优先级要求。
• 一旦开发递增部分，部分的需求将被冻结。

优点

• 采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。因此，增量能够有计划地管理技术风险。
• 每次迭代后，应执行回归测试。在此测试期间，可以快速识别软件的故障元素，因为在任何单个迭代中很少进行更改。
• 测试和调试比其他类型的软件开发方法更容易，因为每次迭代时所做的更改相对较小。这允许对整个产品中的每个元素进行更有针对性的、更严格的测试。
• 客户可以响应功能并查看产品，以了解任何需要或有用的更改。
• 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型

缺点

• 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
• 在开发过程中，需求的变化是不可避免的。很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
• 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析
• 随着产品增加了其他功能，可能会出现与系统体系结构相关的问题，而早期原型中并不明显
• 由增量产生的成本可能会超过组织的成本。

1.6：V、W、X、H模型

为保障软件质量，将测试工作凸显出来，结合测试又演化出了针对测试的过程模型，主要有V模型,W模型,X模型,H模型等

V模型

V 模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终，是瀑布模型的一个变体。

V 模型反映了开发过程和测试过程的关系，在测试软件的过程中起着非常重要的作用。测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应。

左侧对应设计阶段

• 需求分析要分析用户的需要，整理出系统的需求（功能需求），会和用户面谈，建立用户需求文档
• 概要设计是系统设计师根据用户需求文档，分析并理解要开发系统的业务流程的阶段，会产生软件规格文档，软件规格文档是开发阶段的蓝图；
• 详细设计也称为低阶设计，会将设计的系统拆解为较小的单元或是模组，说明每一部分的内容，让程式设计者可以直接写程式。

右侧对应测试阶段

• 单元测试 -> 主要发现编程和详细设计阶段的错误，测试计划在详细设计阶段制定，在编码阶段完成；
• 集成测试 -> 主要发现设计阶段产生的错误，测试计划在概要设计阶段制定，在详细设计阶段完成；
• 系统测试 -> 计划在需求分析阶段制定，在概要设计阶段完成；
• 验收测试 -> 计划会在需求分析阶段就订定，测试计划是由企业用户来进行。

与瀑布模型一样，V 模式是一种传统软件开发模型，在当前互联网软件开发中，局限性还是比较大的！

V 模型的中心思想是研发人员和测试人员需要同时工作，在软件做需求分析的同时就会有测试用例的跟踪。

W模型

V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试” 的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W 模型

W 模型与 V 模型有一个很大的不同，就是 W 模型是一个并行的模型，V 模型是一个串行的模型。W 模型测试是从需求分析开始就开始了，而不是等到编码完成后才开始。并且测试阶段的划分更清楚，而不仅仅是单元测试、集成测试、系统测试，还包括前期的测试计划、测试方案等内容，这更符合现在企业测试的流程。

W 模型具有以下特征：

• 测试阶段划分得更全面，不仅仅是单元测试、集成测试和系统测试。测试的对象不仅是程序，需求、设计等同样要测试
• 测试与开发是并行的，从需求测试就应该开始介入
• 提出尽早测试的概念，这样可以降低缺陷修复成本
• 测试对象不仅仅是程序，还包括需求或其他的相关文档
• W 模型仍然是以文档驱动的传统开发方式的一个变种

X模型

X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。

X 模型左边是单元测试和单元模型之间的集成测试，右边是功能的集成测试，通过不断的集成最后成为一个系统，如果整个系统测试没有问题就可以封版发布。这个模型有一个很大的优点是它呈现了一种动态测试的过程中，也就是测试是一个不断迭代的过程中，这更符合企业实际情况，其他模型更像一个静态的测试过程。

X 模型提倡公司可以根据自身的实际情况确定是否要进行单元测试和集成测试，并不是所有的研发公司都会先做单元测试和集成测试，更多的是直接做系统测试。

在X 模型中还显示了测试步骤，包括测试设计、工具配置、执行测试三个步骤，虽然这个测试步骤并不很完善，但是毕竟将一些主要的内容表现出来了。

X 模型提倡探索性测试，指不进行事先计划的特殊类型的测试，这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误，避免把大量时间花费在编写测试文档上，导致真正用于测试的时间减少。

综上，X 模型具有以下特征：

• 公司可以根据自身的情况确定是否要做单元测试，还是直接做系统测试;
• 测试应该是一个不断迭代的过程，直到封版发布;
• 提倡探索性测试。

H模型

H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。

H模型揭示了一个原理: 软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。

2：敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

2.1：敏捷开发理论

敏捷开发和传统开发（比如瀑布模型）有何区别

敏捷开发的核心是迭代开发（iterative development）。敏捷一定是采用迭代开发的方式。

对于大型软件项目，传统的开发方式是采用一个大周期（比如一年）进行开发，整个过程就是一次"大开发"；

迭代开发的方式则不一样，它将开发过程拆分成多个小周期，即一次"大开发"变成多次"小开发"，每次小开发都是同样的流程，所以看上去就好像重复在做同样的步骤。

敏捷开发有两个主要的好处：一是可以早期交付，二是可以降低风险

敏捷开发的流程

2.2：面向工程管理-极限编程

极限编程(XP)是由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷软件开发中可能是最富有成效的几种方法学之一。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程

极限编程透过引入基本价值、原则、实践方法等概念来达到降低变更成本的目的

价值观和原则

XP实践和生命周期

包含三个闭环的圈：

• 最里面的环围绕个人如何编码和设计；
• 中间的环围绕作为团队如何协作编码和集成；
• 最外围的环面对客户如何协作、计划和交付。

在这个图中，我们看到了 用户故事 ，注意，它很重要，在敏捷中，需求都会定义为 用户故事 ，关于它的内容我们后面还会学到。然后就是根据 用户故事 定义的 发布计划 。我们会在 发布计划 中包含 总体估算 和 隐喻 。在这里，需要记住的是敏捷中的估算都是相对估算，都是不精准的。

接下来，我们会根据 发布计划 和 用户故事 来确定每个 迭代中需要做的事情，也就是 迭代计划 。在这个计划中，通过客户对功能的解释会将 用户故事 进行更加深入的拆分，变成任务。之后就是通过 结对编程 来实现我们的产品。

当 迭代 结束时，或者到了 发布计划 制定的发布结点时，我们就需要通过 小规模发布 来实现产品的迭代、增量开发，从而达到敏捷的能力。

2.3：面向过程管理

2.3.1：Scrum方式

Scrum 是一种敏捷开发框架，采用迭代增量开发模式，强调团队协作与快速适应变化

Scrum 基于经验主义和精益思维。

经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。

Scrum 采纳一种迭代和增量的方法来优化对未来的预测性并控制风险。 Scrum 让一群共同拥有所有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。

总结下来Scrum框架由下面的部分构成：3个角色，3个工件，5个事件，5个价值

2.3.2：Kanban方式

看板本身源于日本丰田公司对精益制造的实践，后延伸到敏捷开发领域

看板工具的实质是：后道工序在需要时，通过看板向前道工序发出信号——请给我需要数量的输入，前道工序只有得到看板后，才按需生产

看板核心实践 - 可视化工作（价值）流：

图中的每个卡片代表一个价值项，如：功能需求、缺陷、技术概念验证等。它们所在的列，表示其所处的阶段。这些价值项，每经过一个阶段（图中的列）都会产生新信息，价值得以增加。例如，需求经过分析阶段，注入了新信息，价值更高。

价值流是价值项从左至右的流动过程，是信息的产出过程，也是价值增加的过程。

价值流动可能会被阻碍。比如，编码因对第三方接口错误而无法进展；测试因没有设备而停滞。图中，红色卡片是对问题和阻碍因素的可视化。标识阻碍因素并推动其解决，促进价值流动。

最终限制系统端到端的流动速度的关键点在于系统瓶颈之处，改善端到端的价值流速，必须从解决瓶颈问题开始。发现看板墙上的瓶颈并不困难，找到最长的队列就可以了，这就和交通系统的瓶颈处，总是出现长长的等待车队是一个道理。上图中的队列出现在测试处，不难看出，测试是价值流动的瓶颈。

价值、价值流，以及问题和瓶颈的可视化，是改善价值的起始，也是其它看板实践的基础。

看板核心实践 - 显式化流转规则：

价值项的“流转规则”是看板开发方法中最典型流程规则，它定义了一个价值项从一个阶段进入下一阶段所必须达到的标准。下图中，给出了某团队其中一项流转规则的实例，定义了从分析阶段进入开发阶段所必须达到的条件。

“流转规则”的显式化，让质量内建于各个阶段——这与精益制造中内建质量的思想是一致的。除各个“流转规则”外，其它重要的流程规则也可以或者需要被显式化，如，团队的协作规则、优先级的定义规则等。

看板核心实践 - 限制在制品数量：

限制在制品数量是看板开发方法的核心机制。

限制在制品数量形成一个与精益制造类似的拉动机制。当一个环节有空余的能力（在制品数目未达上限）时，则从上游拉入新的工作，拉动的源头是最下游的交付或客户需求。与产品制造类似，使用使用拉动系统的好处如下：

• 加速价值流动：限制在制品数量，减少了价值项在阶段间的排队等待，缩短了价值从进入系统到交付的时间，加速了端到端的价值流动。
• 暴露问题：限制在制品数量，让湖水岩石效应产生作用。它让过去被隐藏的问题，如团队协作不良、需求定义错误、开发环境低效、资源分配不均衡等得以显现。

许多号称使用“看板”的团队，并没有限制在制品数量，他们当然也不会得到上述收益。精益制造通过看板向上游传信号，拉动生产。而看板开发方法通过限制在制品数量形成拉动系统，缺乏这一核心机制就不成其为看板。

2.4：测试驱动开发-TDD

测试驱动开发(Test Driven Development, 简称TDD)是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

TDD 追求的是在编写任何实现代码之前，先编写测试用例。从接口使用者的角度思考，帮助驱动出良好设计的接口。当编写代码的人脑子里面想的是「我要什么」，而不再是具体细节的「我要怎么做」的时候，TDD 的目的也就达到了

这部分就比较深奥了，这里贴出几个好的链接，后续学习使用：

• pdai大神
• csdn介绍TDD最高收藏
• 知乎最高赞
• 稀土掘金最高赞
• bilibili大学

2.5：领域驱动开发-DDD

业务和技术细节隔离分开！

DDD的本质就是把技术人员从“独尊技术”的弯路上拉回来，重新把重点放在业务上

比较深奥，中小型项目或者公司根本没有用到的情况，适合非常大的业务情况

下面依然是列举几个好的网址，便于后续学习：

知乎最高赞

个人博客落地实战

掘金最高赞

图灵DDD

DDD的思考

3：中小企业的典型开发

4：精益企业

所谓精益企业就是一个产品系列价值流的不同部门同心协力消除浪费，并且按照顾客要求，来拉动生产。这个阶段性任务一结束，整个企业立即分析结果，并启动下一个改善计划。

国外有家公司叫Scaled Agile, Inc. (SAI)，它推出了SAFe的框架（SAFe for Lean Enterprises）是全球领先的业务敏捷框架。SAFe将精益、敏捷和DevOps的力量集成到一个全面的操作系统中，通过更快、更可预测和更高质量地提供创新产品和服务，帮助企业在数字时代茁壮成长

下图提供了SAFe的精益企业七项核心能力及其二十一个维度的简化视图，以实现业务敏捷性。

所有能力的焦点都是客户, 精益敏捷领导是基础。

六：系统认证

1：能力成熟度模型集成认证

1.1：CMM和CMMI

自从软件工程概念提出以后，出现了许多开发、维护软件的模型、方法、工具和环境，它们对提高软件的开发、维护效率和质量起到了很大的作用。尽管如此，人们开发和维护软件的能力仍然跟不上软件所涉及问题的复杂程度的增长，软件组织面临的主要问题仍然是无法开发出符合预算和进度要求的高可靠性和高可用性的软件。人们开始意识到问题的实质是缺乏管理软件过程的能力。

1987年，卡内基·梅隆大学软件工程研究所率先推出了软件工程评估项目的研究成果–软件过程能力成熟度模型CMM，其研究目的是提供一种评价软件承接方能力的方法，同时它可帮助软件组织改进其软件过程。

CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。该能力成熟度模型使软件组织能够较容易的确定其当前过程的成熟度并识别其软件过程执行中的薄弱环节，确定对软件质量和过程改进最为关键的几个问题，从而形成对其过程的改进策略。软件组织只要关注并认真实施一组有限的关键实践活动，就能稳步的改善其全组织的软件过程，使全组织的软件过程能力持续增长

CMM将软件过程改进分为以下5个成熟级别：初始级别、可重复级别、已定义级别、已管理级别、优化级别

CMM的成功导致了适用不同学科领域的模型的衍生，如系统工程的能力成熟度模型，适用于集成化产品开发的能力成熟度模型等。而一个工程项目又往往涉及多个交叉的学科，因此有必要将各种过程改进的工作集成起来。1998年，由美国产业界、政府和卡内基·梅隆大学软件工程研究所共同主持CMMI项目。CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。

CMMI提供两种表示方法：阶段式模型和连续式模型。

1.2：阶段式模型

阶段式模型的结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版本中有5个成熟度等级。

• 初始的：过程不可预测且缺乏控制。
• 已管理的：过程为项目服务。
• 已定义的：过程为组织服务。
• 定量管理的：过程已度量和控制。
• 优化的：集中于过程改进。

1.3：连续式模型

连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（Capability Level，CL）。CMMI中包括6个过程域等级，等级号为0-5。能力等级包括共性目标及相关的共性实践，这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时，就说该组织达到了那个过程域的能力等级。

能力等级可以独立的应用于任何单独的过程域，任何一个能力等级都必须满足比它等级低的能力等级的所有准则。对各能力等级的含义简述如下：

• CL0（未完成的）：过程域未执行或未得到CL0中定义的所有目标。
• CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
• CL2（已管理的）：其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审。
• CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程集中裁剪得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改造。
• CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则。
• CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。

1.4：申请&认证流程

一般都是找代理，降低认证失败的风险，可以看这个

2：信息安全等级保护认证

在中国，信息安全等级保护广义上为涉及到该工作的标准、产品、系统、信息等均依据等级保护思想的安全工作；狭义上一般指信息系统（APP）安全等级保护。

信息安全等级保护：

• 对信息系统分等级进行安全保护和监管；
• 对信息安全产品的使用实行分等级管理；
• 对信息安全事件实行分等级响应、处置。

《信息安全等级保护管理办法》规定，国家信息安全等级保护坚持自主定级、自主保护的原则。信息系统的安全保护等级应当根据信息系统在国家安全、经济建设、社会生活中的重要程度，信息系统遭到破坏后对国家安全、社会秩序、公共利益以及公民、法人和其他组织的合法权益的危害程度等因素确定。信息系统的安全保护等级分为以下五级，一至五级等级逐级增高：

• 第一级，信息系统受到破坏后，会对公民、法人和其他组织的合法权益造成损害，但不损害国家安全、社会秩序和公共利益。第一级信息系统运营、使用单位应当依据国家有关管理规范和技术标准进行保护。
• 第二级，信息系统受到破坏后，会对公民、法人和其他组织的合法权益产生严重损害，或者对社会秩序和公共利益造成损害，但不损害国家安全。国家信息安全监管部门对该级信息系统安全等级保护工作进行指导。
• 第三级，信息系统受到破坏后，会对社会秩序和公共利益造成严重损害，或者对国家安全造成损害。国家信息安全监管部门对该级信息系统安全等级保护工作进行监督、检查。
• 第四级，信息系统受到破坏后，会对社会秩序和公共利益造成特别严重损害，或者对国家安全造成严重损害。国家信息安全监管部门对该级信息系统安全等级保护工作进行强制监督、检查。
• 第五级，信息系统受到破坏后，会对国家安全造成特别严重损害。国家信息安全监管部门对该级信息系统安全等级保护工作进行专门监督、检查。

申请流程如下

企业自己申请的流程如下

1. 在定级备案的步骤，一级不需要备案仅需企业自主定级。二级、三级是大部分普通企业的信息系统定级。四级、五级普通企业不会涉及，通常是与国家相关（如等保四级-涉及民生的，如铁路、能源、电力等）的重要系统。根据地区不同备案文件修改递交通常需要1个月左右的时间。

2. 定级备案后，寻找本地区测评机构进行等级测评。

3. 根据测评评分(GBT22239-2019信息安全技术网络安全等级保护基本要求。具体分数需要测评后才能给出)对信息系统（APP）进行安全整改，如果企业没有专业的安全团队，需要寻找安全公司进行不同项目的整改。等级保护2.0三级有211项内容，通常企业需要根据自身情况采购安全产品完成整改。

4. 进行安全建设整改后，通过测评。当地公安机关会进行监督检查包含定级备案测评、测评后抽查。

整个流程企业自行做等级保护，顺利的话3-4个月完成，如果不熟悉需要半年甚至更久。优势：与第三方企业对比几乎没有优势劣势：时间长、消耗人力成本高、技术人员不足还可能增加安全建设成本

3：信息安全管理认证

信息安全管理体系标准（ISO27001)可有效保护信息资源,保护信息化进程健康、有序、可持续发展。ISO27001是信息安全领域的管理体系标准，类似于质量管理体系认证的 ISO9000标准。

当您的组织通过了ISO27001的认证,就相当于通过ISO9000的质量认证一般，表示您的组织信息安全管理已建立了一套科学有效的管理体系作为保障

3.1：所需材料

1、组织法律证明文件，如营业执照及年检证明复印件（盖公章）；

2、组织机构代码证书复印件、税务登记证复印件（盖公章）；

3、申请认证组织的信息安全管理体系有效运行的证明文件（如体系文件发布控制表，有时间标记的记录等复印件）；

4、申请组织的简介：

（1）组织简介（1000字左右）；

（2）申请组织的主要业务流程；

（3）组织机构图或职能表述文件；

5、申请组织的体系文件，需包含但不仅限于（可以合并）：

5.1、信息安全管理体系ISMS方针文件；

5.2、风险评估程序；

5.3、适用性声明；

5.4、风险处理程序；

5.5、文件控制程序；

5.6、记录控制程序；

5.7、内部审核程序；

5.8、管理评审程序；

5.9、纠正措施与预防措施程序；

5.10、控制措施有效性的测量程序；

5.11、职能角色分配表；

5.12、整个体系文件结构与清单。

6、申请组织体系文件与GB/T22080-2008/ISO/IEC 27001:2005要求的文件对照说明；

7、申请组织内部审核和管理评审的证明资料；

8、申请组织记录保密性或敏感性声明；

9、认证机构要求申请组织提交的其他补充资料。

3.2：认证流程

第一阶段：现状调研

从日常运维、管理机制、系统配置等方面对贵公司信息安全管理安全现状进行调研，通过培训使贵公司相关人员全面了解信息安全管理的基本知识。

第二阶段：风险评估

对贵公司信息资产进行资产价值、威胁因素、脆弱性分析，从而评估贵公司信息安全风险，选择适当的措施、方法实现管理风险的目的。

第三阶段：管理策划

根据贵公司对信息安全风险的策略，制定相应信息安全整体规划、管理规划、技术规划等，形成完整的信息安全管理系统。

第四阶段：体系实施

ISMS建立起来（体系文件正式发布实施）之后，要通过一定时间的试运行来检验其有效性和稳定性。

第五阶段：认证审核

经过一定时间运行，ISMS达到一个稳定的状态，各项文档和记录已经建立完备，此时，可以提请进行认证。