工作十几年了，看了很多，学了很多，用了很多，但是却不怎么动笔，然而，近来却越发感到学生时代老师天天叨叨的“好记性不如烂笔头”是唯一的真相了。想系统的刷新一下知识体系很久了，总是瞎忙而没有动起来，直到前不久偶然看到极客的架构课程，抬头一看，正好李老师的书在书架上，于是取下来快读一遍，感觉意犹未尽，就报名参加了，也是想借此机会，把自己的知识串联一下，温故而知新。

第一课

本次课程，老师开宗明义：为了架构本次训练营课程。其实本身就是一次架构师日常工作实战的展示，分析问题，提出解决方案，并说服受众。



老师首先从一些JD分析开始，逐一解读关键字，并归纳总结对架构师能力的要求，既有技术上的硬实力，也要有沟通技能上的软实力。整个过程中，一个冰山浮现在我的脑海，多数时候架构师呈现的只是其能力冰山浮于海面上的一角，而海面之下隐藏的才是支撑起其工作的真功夫。



分析完JD，老师罗列很多面试题，一方面和大家互动，一方面激励自查，同时引出知识深度与广度的讨论，最后落在广度要以深度为基础，这和我司所提倡的T型能力模型不谋而合。广度与深度是相辅相成的。只有广度，那只是天桥的把式——嘴把式，肤浅而不能解决问题，犹如身边某自命不凡的“牛人”，看什么都简单，可是技能退化到甚至不能搭建开发环境。不明白小马过河的道理，难不难不能道听途说，会者不难，难者不会。浅尝辄止的技能是想象出来的技能，并不真实。然而只有深度，很可能失去技能迁移的能力。虽精于一门，却无法适应软件构建这个复杂过程，很可能沟通不畅，最终结果依然令人失望。同意老师提到的一通百通的思想，一个打游戏，做运动特别优秀的人，很可能做别的事也会很优秀。这个说法和邓亚萍的观点一致，她也认为不要小看世界冠军们，他们不是只会运动，都是人精，人才，干其他事也能做到杰出。此观点有一潜台词，就是次人要有迁移能力，可以把做好一件事做的能力迁移到另一件事上，不然就是成了专精一门，而无二。



至此，老师总结前面的分析，提出架构师的能力模型，并据此设计本架构训练营课程，包括了软硬两方面能力，既能解决问题，又要能交付文档，与干系人沟通，主导软件从概念到上线运行。



最后，老师展示了软件架构的架构图，令人映像深刻。图中所列架构元素，及其关系正好印证架构是架构元素及元素关系的集合。架构是为系统干系人在抽象的层面解决其关注的问题，并记录。

第二课

次课以架构师最终交付物——架构文档，为切入点。讲解4+1视图文档和主要软件建模工具UML。本课和好的展示了以终为始的观念，比如，从要交付的文档开始本训练营课程，又比如，架构文档中的第一个图是部署图，而不是从一个细分的类图开始架构文档。

4+1中的中心是场景图，场景可以理解为Agile里的Epic/User Story。围绕场景，逐步细化逻辑视图，物理视图，过程视图和开发视图。我理解逻辑视图和过程视图是从静态结构和动态交互两个方面描述软件，物理视图是软件物理分包与部署的视图，最后要由开发视图呈现工作包的分解，是软件与组织架构的融合，是康威定理的表现。

UML是多年前的常用工具，时至今日，反倒很久没有使用了，astah也曾是我的最爱，至今任然安装的是v7，已是几年没有问津了。UML十个图中，有4个静态图和3个动态图为常用工具，有用例图，类图，组件图，部署图，时序图，活动图和状态图。每一种图都能表示不同的抽象粒度，但是要保证同一个图中元素的逻辑层次要一致。推荐自顶向下的分解，即部署图，然后是子系统/组件/类三层分解。



作业

明天作用是餐厅刷卡记账系统，本想完成完整的设计文档，但是就像任何问题一样，已经分析，细节就爆发出来，于是一发不可收拾，这一方面反映出抽象表达能力的不足，另一方面也是缺乏与开发团队默契的前提下，其实很难做出高质量的文档。最后，只好做一小部分以为示例而已。

用例图

部署图

余额查询序列图

支付场景组件序列图

账户服务类图