推荐序一:架构师真正要学会的事情

推荐序一:架构师真正要学会的事情

1. 要学会去看,然后忘掉

有一本书叫《观止》,写的是微软研发Windows NT 的一段故事。“观止”在这里的意思是说“看到这些,就无需再看了”,因为世上之物亦无过于此。20 多年过去,如今微软在操作系统上面临着的种种挑战与困境,其实与《观止》所叙的研发方法、理念与目标有着与生俱来的血缘关系。

另一个与“看”相关的词汇是“所见即可得”(WYSIWYG)。这个词以及与此相关的WIMP(Windows, Icon, Menu and Pointer)曾经主导了整个人机交互的设计理念。也是在20 多年前,Borland 为Windows 桌面系统成功地设计了跨语言的VCL,由此“所见即所得”成为Borland 对“如何更便捷地构建UI”的基本假想,以至于这家伟大的公司在互联网时代来临时决定“用VCL 描述界面的方式来解决‘网站设计’的问题(RadPHP)”。

然而,互联网上的网页是没有WIMP 的;移动设备上的操作系统也不再采用与Windows NT类似的方式开发。

Borland 在几年之前将整个开发工具产品线都卖掉了。当时盛大的一个Delphi 圈子发起了一次“缅怀活动”,组织者说:“爱民,你应该会为那个时代写点什么吧?”

我在那个缅怀网页上写下了五个字:所见即所碍。

2. 要学会去听,然后忘掉

我通常说架构是一种能力,架构角色则是要求你在具体事务中行使某些行为,而架构师则是用来标识这些能力与行为的一个职务。

当一些人将个人成长定义为“职业发展”时,就表现为“怎样成为架构师”这样的问题。对此有三种解决方案,第一种是印一张写着这样头衔的名片,而“是与不是”架构师并不重要;第二种是直接否定这个职务的意义,比如声称敏捷天生就是反架构的,于是“架构师”变成了要打倒的对象,所以成不成为这个将被打倒的对象也就不重要了;第三种则干脆声称“人人都是架构师”,既然人人都是了,那么“如何成为”也自然就不重要了。

我们大多数人都具有架构的能力,并且也或多或少地行使某些架构角色的行为,唯一缺乏的只是一个叫做“架构师”的头衔而已。问题出在我们总是期望别人通过这样的头衔来认可自己。于是我们为自己贴上这样或那样的标签,然后跟别人持有的同种标签去比对,期求出现一致或找出某种差别。于是我们听到种种声音:某某某真的是/不是、像/不像架构师;如果是架构师,那么就要这样那样,以及怎样怎样;其实这个架构、这样的架构,或某种架构应该怎么做;以及架构是什么,架构师是什么,等等。回顾“三种解决方案”,仍是困在这样的认可求同之中,与之在做着种种斗争罢了。

其实不单是你的所见阻碍了你自己,你还被别人的所见阻碍着。

3. 要学会去做,然后忘掉

朋友跟我聊他家的两岁小孩:我刚把桌子收拾好,一转眼杯子碗筷什么的都全摔地上了。我问:“怎么了?”他说:“小孩子什么也不懂啊,她看到桌布觉得喜欢,就一把抓过去……”

小孩子没能看到桌子上还有杯子,但正因为他们的视线里没有杯子,他们的行动才简单直接,才直达需求,才迅速。而我们的眼睛里有杯子、桌子、桌布等一切,我们经年累月地维护着其中的次序与关系直到这些东西混成一体,然后我们便日日坐守在它们的面前,而又无觉他们的存在。

正是我们自己不知不觉地设定了这些事物之间的界线,并把这些界限、层次与逻辑井然的东西称为“系统”。当我们从那些无序的事物中识别出了这样的“系统”并用一些概念、名词去定义了它们之后,我们对此的一切知识也就固化了。当这种秩序被建立起来之后,我们也就得到了对有序和无序(没有你所设定的“这种秩序”)价值的识别与肯否;当我们设定了种种价值、观念、观察与系统的模型概念之后,也就完成了这个系统的架构。

但这一过程,包括完成这一架构——它可以命名为“世界观”——的方法以及结果,在本质上不过是让你从一个格子跳到了另一个格子而已。我们处在种种界限之中,再也无法回到两岁小孩的、一切无碍的视角:在那个视角下,根本就没有所谓的界线。你之所以时时在寻求跨界,其实是源自你假设了“存在界线”,这就如同全栈的含义其实是“没有栈”,而当有人信心满满地要“成为全栈工程师”时,他的眼里便又有个“这个栈”的存在。

所谓跨界不是指你能力与方法上的变化,你的作为取决于你的格局,你的格局取决于你的所见。

4. 要学会超越

架构师需要超越自己与别人的所见,因为你观察与架构的对象称为“系统”,你看到系统多少的真相,决定了你用怎样的影像去表现它,并进而推进与实现这种影像,亦即是架构。我们既已知道的、理解的、明白的,形成了我们的知识与行为的一切,却也正是阻碍着我们前进的东西。

这些障碍正是你以为你最珍视的、最不可放弃的、最鲜血淅沥体验过的那些经验与成就。在这些所得与所碍中挣扎与决策,就是架构师的全部职责。因此作为架构师,你需要能够超越自已对系统的既有认识,看到你在光明中——显而易见之处——所未见的,这是你驱动系统架构进化的主要动力。

所以架构中最难超越的并不是某个大师或前辈,而是你以及你为自己所作的设定。当你设定了“架构师”这个目标,便设定了这个目标所表达的某种影像(角色),你最终可能变得跟这个影像完全一致——成为所谓的“真正的架构师”,但你仍不过是困囿于对这个“角色”的一个假设/设定而已。唯一破局的方法是:超越别人对某个角色的定义,将自己做成这个角色。

至此,你是否还在这个角色之中,就是你的觉悟了。

周爱民
现任豌豆荚架构师
前盛大网络平台架构师、支付宝业务架构师

目录

  • 版权声明
  • 献词
  • 推荐序一:架构师真正要学会的事情
  • 推荐序二
  • 译者序2.0
  • 关于本书
  • 软件架构培训
  • Part Ⅰ 什么是软件架构
  • 第 1 章 什么是架构
  • 第 2 章 架构的种类
  • 第 3 章 软件架构是什么
  • 第 4 章 敏捷软件架构是什么
  • 第 5 章 架构对上设计
  • 第 6 章 软件架构重要吗
  • 第 7 章 问题
  • Part Ⅱ 软件架构的角色
  • 第 8 章 软件架构的角色
  • 第 9 章 软件架构师应该编码吗
  • 第 10 章 软件架构师应该是建造大师
  • 第 11 章 从开发者到架构师
  • 第 12 章 拓展T
  • 第 13 章 软技能
  • 第 14 章 软件架构不是接力运动
  • 第 15 章 软件架构要引入控制吗
  • 第 16 章 小心鸿沟
  • 第 17 章 未来的软件架构师在哪里
  • 第 18 章 每个人都是架构师,除非他们有其他身份
  • 第 19 章 软件架构咨询师
  • 第 20 章 问题
  • Part Ⅲ 设计软件
  • 第 21 章 架构驱动力
  • 第 22 章 质量属性(非功能需求)
  • 第 23 章 处理非功能需求
  • 第 24 章 约束
  • 第 25 章 原则
  • 第 26 章 技术不是实现细节
  • 第 27 章 更多分层等于更高复杂度
  • 第 28 章 协同设计是一把双刃剑
  • 第 29 章 软件架构是对话的平台
  • 第 30 章 SharePoint项目也需要软件架构
  • 第 31 章 问题
  • Part Ⅳ 可视化软件
  • 第 32 章 沟通障碍
  • 第 33 章 对草图的需要
  • 第 34 章 无效的草图
  • 第 35 章 C4:语境、容器、组件和类
  • 第 36 章 语境图
  • 第 37 章 容器图
  • 第 38 章 组件图
  • 第 39 章 是否包含技术选择
  • 第 40 章 你会那样编码吗
  • 第 41 章 软件架构和编码
  • 第 42 章 你不需要UML工具
  • 第 43 章 有效的草图
  • 第 44 章 C4的常见问题
  • 第 45 章 问题
  • Part Ⅴ 为软件生成文档
  • 第 46 章 代码不会讲述完整的故事
  • 第 47 章 软件文档即指南
  • 第 48 章 语境
  • 第 49 章 功能性概览
  • 第 50 章 质量属性
  • 第 51 章 约束
  • 第 52 章 原则
  • 第 53 章 软件架构
  • 第 54 章 外部接口
  • 第 55 章 代码
  • 第 56 章 数据
  • 第 57 章 基础设施架构
  • 第 58 章 部署
  • 第 59 章 运营和支持
  • 第 60 章 决策日志
  • 第 61 章 问题
  • Part Ⅵ 开发生命周期中的软件架构
  • 第 62 章 敏捷和架构的冲突——神话还是现实
  • 第 63 章 量化风险
  • 第 64 章 风险风暴
  • 第 65 章 恰如其分的预先设计
  • 第 66 章 初识软件架构
  • 第 67 章 问题
  • Part Ⅶ 附录金融风险系统
  • 第 68 章 金融风险系统
  • Part Ⅷ 附录:“技术部落”的软件指南