课后总结 -20200606

在本周的学习过程中，我们首先明确了什么是架构师这一基础概念，并对架构师这一角色在日常工作的过程中应该具备的能力、需要解决的问题及面临的挑战有了初步的认识，并引出了本次架构师训练营的整体课程安排。值得注意的是，通过对“什么是软件架构”这一问题的剖析，使我明确了“软件架构的重点在于相关方”这一重要认识，认识到想要让自己的架构设计能够顺利落地，除了具备相应的能力和知识外，更重要的是在于解决各个相关的部门、相关的人对于软件的需求，减少甚至排除相关部门的顾虑，以及提升相关人员相关部门的价值。反思自己在之前的工作过程中偶尔出现的“炫技”思想，认为只有使用 XX 框架，应用 XX 结构，实现出来的软件才是优秀、有价值的，结合上述关于软件架构重点在于相关方的结论而言，就显得过于粗浅，甚至过于自私，因为这种态度本质上是在用公司和相关部门的资源给自己创造新技术的实践机会，是让其他人冒着系统不稳定、软件质量更加无法预估的风险为自己的简历增加所谓的“亮点”。这种想法现在看来是极其错误的，需要在今后的工作中努力避免。

周六的课程中我们学习了 4+1 架构视图，对于 4+1 架构视图的概念其实我早已经在大学时和工作之后有所接触，实质上就是各种 UML 视图，包括用例图、时序图、类图等。而 4+1 视图概念的出现，实际上是把之前已有的知识重新梳理了一遍，从软件架构的层面说明仅仅使用一种图无法向所有相关方传达所有与设计有关的信息，因此将原有的视图划分为逻辑视图、过程视图、物理视图、开发视图、场景视图，针对不同相关方关心的问题，以不同的图进行说明，形成一个“视图集”。画图的过程本质上就是对软件进行建模的过程，是对问题进行抽象的过程。通过 UML 视图，可以进一步帮助自己梳理原本零散的想法，并将一部分设计问题提前暴露出来，便于及时进行调整，避免软件已进入实际编码阶段甚至联合测试阶段时再发现问题，可以大量减少人力成本的浪费；此外，UML 视图本身也是一个很好的与其它相关者沟通的工具，用语言和文字需要很大篇幅才能够描述清楚的事情，可能通过一两张图就能传达的更加清晰、准确，这是图比起文字信息量更加丰富的优势决定的。

通过本周的课程，使我认识到对问题的抽象是架构设计的重要一环。日常工作中随着敏捷开发的推广，以及相关部门对开发周期的压缩，使得我自身越来越忽视对系统的设计工作。而本周的课程帮助我梳理了软件设计可以使用的工具，并通过课后作业让我认识到了设计本身并不那么难，各种 UML 视图画起来也并非那么复杂，而通过画图可以帮助自己从概括到具体的思考整个系统的功能，提早发现潜在的风险，是一件“磨刀不误砍柴工”的事情。在今后的工作中我也应该更加重视软件的设计，并利用好工具辅助自己思考，可以帮助自己开发出质量更高、更稳定的软件。