mozhan的专栏

目录1 将学习融入日常生活2 将局部经验转化为全局改进3 预留组织学习和改进的时间从以下方式制订有关提高安全性、持续改进和边做边学的制度：建立公正的文化，使人们有安全感；通过故障注入的方式，增强生产环境的可靠性；将局部发现的经验知识转化成全局的提升；预留专门的时间段，用来开展组织性的改进和学习活动。我们还将创造一种机制，将团队在某个领域里学到的经验迅速地应用和推广到整个组织里，将局部的改进转化成全局的优化，这样能创造出一种更安全、更有弹性的工作文化，让团队成员乐于参与其中，并帮助他们在最大程

前面几篇总结了DevOps的基本概念和流动的技术实践，这篇总结下反馈的技术实践。

接着上篇实践篇2（https://blog.youkuaiyun.com/jinzhengquanqq/article/details/115353649），一起来看看流动的技术实践。1 部署与发布将软件发布到生产环境和部署到测试环境是有差异的，这些差异应该被封装在一组配置文件中。部署与发布之间的主要区别在于回滚的能力。测试环境及生产环境的部署与回滚，都应该是部署流水线具体实现中的组成部分。创建发布策略：创建发布测试的最重要部分是在项目计划阶段就与应用程序的所有干系人会面，讨论关键在于，要对整个应用程序的.

接着上篇实践篇1（https://blog.youkuaiyun.com/jinzhengquanqq/article/details/115320511），一起来看看流动的技术实践。创建必要的技术实践和架构，从而使开发到运维的工作能够稳定快速的流动，并确保不会造成生产环境的混乱或服务的中断，可以通过一套被称为持续交付的技术实践来实现。持续交付包括打好自动化部署流水线的基础，确保团队能够使用自动化测试持续验证代码是否处于可部署状态，保证开发人员每天都将代码提交到主干，以及构建有利于实现低风险发布的环境和代码。通过将

接着上篇概念篇，一起来看看DevOps的实践从哪里开始，都需要做些什么？

1， 软件交付有哪些坑？2，解决策略是个啥？3，DevOps生态圈

重构，对软件内部结构进行调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。重构什么时候开始：如果采用TDD的方式开发，那重构已完全融入到了开发过程中，如果没有采用TDD，通常有4个时机可以考虑要不要重构：事不过三、添加新功能、修复缺陷、代码评审重构什么时候停止：通过所有测试、没有重复、表达意图、最简化代码重构前提：在重构前一定要写测...

<br />静态结构和动态行为，uml提供图来描述系统的结构和行为。uml提供图来描述系统的结构和行为，类图最合适于描述系统的静态结构，类，对象以及它们之间的关系，而状态，序列，协作和活动图则适合于描述系统的动态行为，即描述系统中的对象在执行期间不同的时间点是如何动态交互的。<br />系统中的对象需要相互通信：它们相互发送消息。通常情况下，一个消息就是一个对象激活另一个对象中的操作调用，对象是如何进行通信以及通信的结果如何则是系统的动态行为，也就是说，对象通过通信来协作的方式以及系统中的对象在系统的生命期

普通通用化具有通用化关系的两个类之间是继承关系。父类与子类的通用化关系图示为一个带空心三角形的直线，空心三角形紧挨着父类。父类中公有的成员在被继承的子类中仍然是公有的，而且可以在子类中随意使用；父类中的私有成员在子类中也是私有的，但是子类的对象不能存取父类中的私有成员。如果既需要保护父类的成员，又需要让其子类也能存取父类的成员，那么父类的成员的可见性应设为保护的。具有保护可见性的成员名字前面通常加一个“#”号，类图中可以不表示该符号。受限通用化给通用化关系附加一个约束条件，进一步说明该通用化关系的使用方法或

<br />构成面向对象模型的基本元素有类，对象，类与类之间的关系等。<br /> <br />类图是用类和他们之间的关系描述系统的一种图示，是从静态角度表示系统的，因此类图属于一种静态模型。类图是构建其它图的基础。<br />当类图中存在多个类时，类与类之间的关系可以用表示某种关系的连线，把他们连接起来。<br /> <br />二，定义类<br />定义类，也就是将系统要处理的数据抽象成类的属性，将处理数据的方法抽象为操作，对于建模者所定义的类通常要有这样二个特点：1，使用来自问题域的概念；2，类的名字

<br />用例图：用例模型是用例图描述的，用例模型可以由若干个用例图组成，用例图中包含系统，角色和用例等三种模型元素，图示用例图时，既要画出三种模型元素，同时还要画出元素之间的各种关系（通用化，关联，依赖）<br /> <br />用例内容被看作用例元素的文档性质。<br /> <br /> <br />系统：是用例模型的一个组成部分，代表的是一部机器或一个商务活动，而并不是真正实现的软件系统，系统的边界(功能)用来说明构建的用例模型的应用范围。准确定义系统的边界不是件容易的事，一般的作法是，先识别出系统

<br />一，简介<br />uml语义是定义在一个四层建模概念框架中，这四层分别是：<br />元元模型层：组成uml最基本的元素"事物"，代表要定义的所有事物。<br />元模型层：组成uml的基本元素，包括面向对象和面向组件的概念。<br />模型层：这一层中的每个概念都是元模型层中概念的一个实例。<br />用户模型层：这层中的所有元素都是uml模型的例子。<br /> <br />uml描述的系统视图：<br />用例视图:从用户角度看到的系统功能<br />逻辑视图：系统静态结构，描述系统内部