Xiaowu/20230221 (microsoft#777)

* update * update * update * update * update * update * Update 12.2 业务场景架构.md * update * update * Update 12.2 业务场景架构.md * up * update * update * Update 13.1 与架构相关的概念.md * update * Update 13.8 架构设计的最佳实践.md * updata * update * Update 12.0 技术架构.md * Update 13.2 业务场景架构.md * update * update * Update 12.7 康威定律.md * Update 12.2 技术架构模式.md * Update 13.1 与架构相关的概念.md * update * update * update * update * update * update * update * Update 13.4 架构设计最佳实践.md * update * Update 13.4 架构设计最佳实践.md * update * Update 13.4 架构设计最佳实践.md * update * update * update * update * update * update * updaate * update * update * update * update * update * Update 13.7 手机Edge浏览器概要设计.md * update * update * Delete Slide36.SVG * update * update * Update 13.7 手机Edge浏览器概要设计.md * Update 13.5 架构设计最佳实践.md * update * update * update * Update 13.8 三高.md * update * Update 13.8 三高.md * update * update * update * update * update
sddhsd · Mar 22, 2023 · 16c5269 · 16c5269
1 parent 5f06420
commit 16c5269
Show file tree

Hide file tree

Showing 102 changed files with 2,553 additions and 643 deletions.
diff --git a/基础教程/A5-现代软件工程（更新中）/第2步 - 个人与职业/第3章 - 认知能力/3.4 系统化思维能力.md b/基础教程/A5-现代软件工程（更新中）/第2步 - 个人与职业/第3章 - 认知能力/3.4 系统化思维能力.md
@@ -322,6 +322,8 @@ OK，如果你能够从以上几个方面分析好自己当前的境遇，判断
 
 ### 3.3.6 环形系统与思维形式
 
+环形系统，在生活中貌似不常见，但是其实人类本身就生活在一个环形的大自然环境中，虽然封闭但是可以自我修复，以达到最平衡的状态。古人总结出来的太极和五行理论就是环形系统。
+
 <img src="img/Slide20.SVG"/>
 
 图 3.3.7 环状系统的负反馈

diff --git a/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.2 阶段任务的投入与产出.md b/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.2 阶段任务的投入与产出.md
@@ -86,7 +86,7 @@
 对于大中型系统，需要架构设计，因为要考虑框架的灵活性、可维护性等。在架构设计文档中要包括 4+1 视图：
 - 场景视图
 - 逻辑视图
-- 进程视图
+- 运行视图
 - 开发视图
 - 物理视图
 

diff --git a/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.5 敏捷开发流程.md b/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.5 敏捷开发流程.md
@@ -281,4 +281,6 @@
 
 也可以叫做 postmortem（事后检讨）。
 
-2、4、5三个会议有点儿罗嗦，可以合并成一个或两个会议，只要大家能分清楚开会时在讨论什么主题即可。
+【最佳实践】2、4、5三个会议有点儿罗嗦，可以合并成一个或两个会议，只要大家能分清楚开会时在讨论什么主题即可。
+
+【最佳实践】敏捷开发流程是一把双刃剑，已经有过严格的软件工程规范训练的团队可以考虑使用，而新手尽量避免使用，避免“萝卜快了不洗泥，最终用户嘴啃泥”的情况发生。
diff --git a/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.7 开发流程与验证工具的选择.md b/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.7 开发流程与验证工具的选择.md
@@ -1,6 +1,8 @@
 
 ## 5.7 开发流程与验证工具的选择
 
+（这部分可以考虑挪到 11 章）
+
 ### 5.7.1 采用合理的开发流程
 
 #### 顺序开发与敏捷开发的对比
@@ -227,3 +229,45 @@ MVP 最小可行产品与 4.6 节中讲的“垂直切片”的概念不完全
 而图 5.7.4 的右子图展示了最终的完美产品，它应该在软件质量的各个特性上都是平衡的，而非金字塔形。
 
 从一定程度上来说，最小可行产品的概念更像是 4.4 节中的小型软件开发流程，所以，从中也可以看到，中大型软件和小型软件的开发流程其实是互通的，可以互相借鉴，或者是最终都可以通过系统分解而归结到小型软件上。
+
+
+### 5.7.3 CI/CD
+
+解决上述问题的手段就是集成，从一开始就集成，并且不断的集成，反复的将拆分的子系统、模块、组件重新组合，看看是否能够顺利组合起来，并且保证功能的不变。
+
+        实现上述不断地集成以及成果物交付的过程就是持续集成和持续交付：
+
+        1.持续集成：指对代码的提交，构建，测试的过程，这是一个持续、反复的过程。
+
+        2.持续交付：指将集成好的交付物，例如war、jar或者容器镜像，部署在联调环境，或者预发环境的过程。
+
+        以下是本项目采用的一个持续集成、持续交付的过程，研发团队在项目实施过程中要严格遵守：
+
+
+<img src="img/Slide24.JPG"/>
+
+新加了一张图
+
+
+持续集成、持续交付的基本流程如下：
+
+            1. 代码开发，完成分配的任务。
+
+            2.  每天提交代码，降低代码集成的风险。采用SVN的提交方式，后提交者有责任去merge，保证代码的编译通过和测试通过。
+            3. 专人定期审核提交的代码，把控代码质量。
+
+            4. 代码审核完毕之后，触发编译过程，完成代码编译。
+
+            5. 编译完成，进行单元测试。要求每个类都要有单元测试，并且单元测试覆盖率要达到一定的指标。单元测试要有带Mock的模块内的集成测试。如果单元测试不通过，则统计后发邮件，抄送所有的人。
+
+            6. 单元测试通过以后，上传成果物（war、jar或其它）至Nexus私服。
+
+            7. 如果采用私有云，并且使用docker容器，则需要编译Dockerfile，使用Docker镜像作为交付，能够实现更好的环境一致性，保证原子的升级和回滚。
+
+            8. 每天下班前，当天的代码需要提交到库中去，晚上会做一次统一的环境部署和集成测试。这个集成测试或者叫回归测试每天晚上都做，都是在一个全新的环境中。如果某一天测试不通过，则会发邮件通知。
+
+            9. 一个周期完毕，进行UAT测试。如果测试不通过，则会发邮件通知，开发人员要及时更正。
+
+           10.UAT测试通过以后，准备上线到生产环境。建议采用灰度发布或蓝绿发布机制，分批次发布、切换流量。一般情况下，具有权限的管理人员通过自动化脚本进行部署。
+
+        通过持续集成、持续交付这套完整的流程，层层保证质量，保证项目可以按时按质的完成，减少项目的实施风险。
diff --git a/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.8 练习 - 代码管理与流程管理工具.md b/基础教程/A5-现代软件工程（更新中）/第3步 - 团队与流程/第5章 - 开发流程/5.8 练习 - 代码管理与流程管理工具.md
@@ -18,7 +18,7 @@
 - Workspace 工作区
   你电脑本地看到的文件和目录，在 Git 的版本控制下，构成了工作区。
 
-<img src="img/Slide24.JPG"/>
+<img src="img/Slide25.JPG"/>
 
 图 5.8.1 Git 工作流
 
@@ -58,15 +58,15 @@ Git 的使用流程如下：
 
 先登录 Azure DevOps 网站，建立团队和项目。
 
-<img src="img/Slide25.JPG"/>
+<img src="img/Slide26.JPG"/>
 
 图 5.8.2 项目流程类型与主菜单
 
 一共有四种类型可选：敏捷流程、基本流程、Scrum 流程、CMMI 流程。如果选择“敏捷流程”，则 Backlog 中的层次关系将如图 5.8.2 的左子图所示，具体的例子如中子图所示，而右子图展示了 Azure DevOps 的左边栏的主菜单，我们只关心 Boards 下面的 Boards, Backlogs, Sprints。
 
 #### 2. Backlogs - 创建产品计划
 
-<img src="img/Slide26.JPG"/>
+<img src="img/Slide27.JPG"/>
 
 图 5.8.3 待办事项 Backlogs
 
@@ -87,7 +87,7 @@ Git 的使用流程如下：
 
 #### 3. Boards - 添加具体工作内容并管理
 
-<img src="img/Slide27.JPG"/>
+<img src="img/Slide28.JPG"/>
 
 图 5.8.4 工作版内容管理 Boards
 
@@ -99,7 +99,7 @@ Board 中有四列分栏，分别是 New、Active、Resolved、Closed，状态
 
 #### 4. Sprints - 制定冲刺计划
 
-<img src="img/Slide28.JPG"/>
+<img src="img/Slide29.JPG"/>
 
 图 5.8.5 冲刺计划 Sprints
 
@@ -117,7 +117,7 @@ Board 中有四列分栏，分别是 New、Active、Resolved、Closed，状态
 - Dashboards - 仪表板
   在主菜单的 Overview 下面。
 
-<img src="img/Slide29.JPG"/>
+<img src="img/Slide30.JPG"/>
 
 图 5.8.6 仪表板 Dashboards
 

diff --git a/基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第7章 - 需求分析/7.2 需求逻辑分析.md b/基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第7章 - 需求分析/7.2 需求逻辑分析.md
@@ -62,7 +62,7 @@
   - 毛毛：“电子邮件是无纸办公的重要手段，倒是可以考虑增加这个功能。”
   - 木头：“用户实际上是想通过网络的方式把自己的意见快速准确地转达给其它人，那不如我们后期考虑在 Azure 上搭建一个服务器吧，这样大家都可以分享自己的见解。”
 
-【最佳实践】就如同亨利福特遇到的情况，用户希望有一匹快马，但其实用户需要的只是“快”，而不是“马”，“快”是真正的需求，“马”只是载体，所以福特开始造新的载体——汽车。理解用户的真实意图，用自己的专业知识提供解决方案。
+【最佳实践】就如同亨利·福特遇到的情况：福特问用户在交通方面有什么需求，用户说“希望有一匹快马”。但其实用户需要的只是“快”，而不是“马”，“快”是真正的需求，“马”只是载体，所以福特开始造新的载体——汽车。理解用户的真实意图，用自己的专业知识提供解决方案。
 
 ### 7.2.2 卡片分类
 

diff --git a/基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.10 需求规格说明书.md b/基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.10 需求规格说明书.md
@@ -24,7 +24,7 @@
 
 ### 8.10.2 需求规格说明书的模板
 
-#### Assumption/Background 假定和背景
+#### 1. Assumption/Background 假定和背景
 
 在需求规格说明书中，首先要简单讲解一下项目或产品的大概背景。可以分成两种情况：
 
@@ -36,23 +36,23 @@
 
    *我们发现大部分研究员都是用 Edge 浏览器和 OneNote 进行阅读和做笔记，非常不方便，所以想在 Edge 浏览器上开发一个扩展插件，来解决做笔记的需要。*
 
-#### Goal/Non-Goal 目标和非目标
+#### 2. Goal/Non-Goal 目标和非目标
 
 仍然沿用读论文工具的例子：
 
 *Goal：解决 PDF 的标记问题。*
 
 *Non-Goal：不准备支持 Word 文档格式，不支持触摸输入。*
 
-#### Persona/Scenario 典型用户与场景
+#### 3. Persona/Scenario 典型用户与场景
 
 有了典型用户后，就要把该用户“放进”具体的应用场景中。Scenario 的意思，就是要把用户放进一个真实的故事片段中，来检验其可行性。
 
 比如前面所述的木头与神经网络课程的故事，用典型用户木头（老师）和毛毛（学生）作为故事的主角，串连起了两个故事片段，在故事中提及了大量的电教课程细节，都可以使用微软提供的技术方案来解决。
 
 反过来看，就是Surface Hub、Azure、OpenPAI 等设备、服务、软件，都应该提供什么功能，才能满足大学电教课程的需要。设计人员坐在办公室冥想是想不出来的，必须到教学现场观察一下上课的情况，才能够设计出相应的产品，然后再泛化。用故事场景（即Scenario）的形式来描述，就是还原现场的一种有效方法。
 
-#### Feature/Function list 特性与功能列表
+#### 4. Feature/Function list 特性与功能列表
 
 Function 和 Feature 不是同一层意思：
 
@@ -65,7 +65,7 @@ Function 和 Feature 不是同一层意思：
 
 所以，Spec 既要有功能（Function）列表，又要有特性（Feature）列表。功能列表通常由用户指定，而特性列表则由 PM 在需求分析的基础上给出，要具体到软件界面元素，比如是选择菜单还是点击按钮，出现的是一个数据列表框还是条形图，等等。
 
-#### Condition/Performance 条件和性能
+#### 5. Condition/Performance 条件和性能
 
 一般指运行环境的要求或者限制，以及在这一运行环境下的系统性能指标。比如：
 
@@ -75,15 +75,15 @@ Function 和 Feature 不是同一层意思：
 
 *网站允许200个用户并发，每个用户的响应时间为50毫秒。*
 
-#### UI/UX 用户界面与交互
+#### 6. UI/UX 用户界面与交互
 
 复杂软件的用户界面和交互，是需要 Designer 参与的，会提供全套的界面元素设计和交互设计。如果是简单的功能，PM 可以根据以有的界面元素直接给定。
 
 比如，软件在某一时刻要弹出一个消息，那么消息框的大小、颜色、文字、位置，都可以参考软件已有的消息框设计直接给出，就不用通过 Designer 了。
 
 在需求阶段，可以给用户提供一个界面草稿，比如：这个 APP 的界面打算设计成左右分屏的，就像 Outlook 那种三级窗口的形式，功能按钮都在左边栏，阅读区在左侧主屏，辅助区在右侧小屏。一些细节的设置用对话框的形式展现。
 
-#### Schedule/Plan 计划和日期
+#### 7. Schedule/Plan 计划和日期
 
 给出项目的几个关键点，如：
 

diff --git a/基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.0 技术架构.md b/基础教程/A5-现代软件工程（更新中）/第6步 - 设计与实现/第12章 - 技术架构/12.0 技术架构.md
@@ -0,0 +1,29 @@
+
+
+<img src="img/Slide1.SVG"/>
+
+技术架构是一个很模糊的概念。
+
+<img src="img/Slide2.SVG"/>
+
+
+https://blog.csdn.net/lfsf802/article/details/8487990
+
+https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
+
+https://zhuanlan.zhihu.com/p/41395345
+
+https://blog.csdn.net/Jayphone17/article/details/103651076
+
+https://zhuanlan.zhihu.com/p/41395345
+
+https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-a55ad27726d6
+
+https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
+
+https://max.book118.com/html/2016/1115/63079375.shtm
+
+https://blog.csdn.net/hguisu/article/details/78259898
+
+
+https://help.aliyun.com/document_detail/207135.html
diff --git a/...第6步 - 设计与实现/第13章 - 架构模式/13.1 架构模式演化的故事.md → ...第6步 - 设计与实现/第12章 - 技术架构/12.1 技术架构演化的故事.md b/...第6步 - 设计与实现/第13章 - 架构模式/13.1 架构模式演化的故事.md → ...第6步 - 设计与实现/第12章 - 技术架构/12.1 技术架构演化的故事.md
@@ -1,4 +1,4 @@
-## 12.1 架构模式演化的故事
+## 12.1 技术架构演化的故事
 
 还记得第一章中关于“木头与软件工程的故事”吧？这里有另外一个版本，是同样的应用场景，但是想说明的是软件**技术架构**演化的故事。**架构**这个词包含好几个子概念，本小节中只讲其中的**技术架构**。