1. 能简单地介绍一下自己吗？

我叫肖鹏，目前在澳大利亚国民银行做架构师。在来澳洲之前在ThoughtWorks中国办公室工作。

2. 近年来，国内最火的莫过于中台，你觉得为什么会出现这样的现象？能不能为大家介绍一下软件工程能力和中台的关系？

我对中台这个概念的理解更多的来自于阅读国内同学的文章和结合过往的“Capabilitiy”（能力）的概念引申，所以可能有很多不准确的地方。

一种新的解决方案的出现往往是由问题推进的。所以要理解中台，就要回去看它要解决什么问题？这方面王健同学在《中台的第一性原理》里面已经有比较深入的论述了。我把结论放到这里供大家参考：

中台所代表的企业架构向平台型演进的过程，本质上就是企业在发展过程中，随着对于市场信息认知不断提升，在不确定性中寻找确定性，持续在跨业务线探索通用最佳实践（Best Practice），并以中台层承载，并最终用于支撑和实现企业对于业务发展的快速响应、复制与增强的过程。

这一点上澳洲的企业也有类似的趋势。虽然不如中台这个概念被提出的如此明确，我服务过的几家大型企业Kmart、澳洲邮政、澳洲国民银行都提出了”能力“的概念。以Kmart为例，底层的能力可能包括产品定义、供应商管理、定价管理、订单管理等等。在银行内部则会有银行卡、支付、渠道、贷款、反洗钱等等。

在我看来，中台的建设是一个解决复杂性的一个思路。如果我们把视野收窄到软件开发领域，就是要解决下面这几个老大难问题：

集成——不同的系统如何集成，有没有成熟的”模式“（Pattern）；所谓的成熟是指这些Pattern是经过验证的，在功能需求和非功能需求上都解决的比较好。
一致性——企业在成长的过程中几乎必然的会出现一致性问题：这包括一个功能有多种实现的问题；一个数据有多种表现；同一个术语可能在不同的系统中表示不同的含义；而相同的实体在不同的系统中又可能会有不同的名词。这些问题反过来会影响用户的体验，甚至直接影响业务。
系统边界——大型企业中系统边界模糊的情况非常常见。比如对于邮局来说，投递系统可能保存了客户的地址；客服系统系统也可能保存了客户的地址。除了一致性问题以外，还要考虑每个系统的边界在什么地方，或者说某个职责是否属于这个系统。

这些问题可以说几十年来都是存在的，为什么这个概念在最近几年火起来了呢？从商业的角度，在互联网基础设施越来越完善的今天，数字化服发展和竞争使得企业有动力对服务进行整合。从技术的角度讲，我认为有两个主要的原因：

微服务；
微服务；

你没有看错，我写了两个微服务。

一方面，微服务暴露甚至加重了问题。原来企业往往只有一两个大型系统，虽然这样的架构有这样那样的问题，但是这些系统内部的数据和状态往往只有一份，天然是一致的。随着微服务架构的兴起，数据的存储越来越零散。同一份数据以不同的形式保存在不同的系统中，经历不一样的生命周期。这就导致了集成点越来越多、集成模式越来越复杂、数据一致性越来越差、系统边界越来越模糊。

另一方面，微服务同时也给出了比较好的解决方案。随着REST、Message Queue等基础架构风格的深入人心，系统的表达能力和团队获取共识的速度都得到了极大的增强。所以，它也使得大规模的、系统性的整合企业“能力”成为可能。

回到你问的问题上面，软件工程能力和中台的关系是什么样的？

尽管有了微服务这样的较好的解决方案，实施中台也绝非易事。中台的实施对于软件工程提出了非常高的要求。从逻辑层面上非常简单的事情，到了实施层面就会面对非常大量的细节问题。这些细节问题既不可能通过购买产品解决，也不可能通过一两个天才程序员解决。这个时候考验的就是软件工程能力——或者用白话说就是——能把一帮人组织在一起交付一个软件系统的能力。

软件工程能力是基础，中台是目标。没有坚实的软件工程能力作为基础，中台就是空中楼阁。退一步说，中台的设计也应当是与软件工程能力相适应的。如果监控、审计、自动化测试方面做的不到位，贸然对架构大动筋骨，实施所谓的中台改造，结果很有可能是灾难性的。

3. 从你的观察，国内外的研发团队都有哪些特点和区别？

我来澳洲之前服务过的最后一家公司是ThoughtWorks。从工作方式上讲，对我来说差别不大。在细微的地方有一些差别。我的观察可能不具有代表性。

首先，加班相对比较少、休假比较有计划性。国内也有不少不怎么加班的公司。澳洲普遍的加班相对少一些。基本上到了下班时间大家就收拾东西回家了。今天没有做完的事情留给明天去做。大家休假的时候也较少考虑对项目的影响。可能跟项目进度本来也慢，休几周假回来也啥影响。

第二，软件工程普遍比较重视。因为我没有近距离接触国内公司好多年了，不知道国内现在软件工程的现状。想必很多公司的软件工程是不错的。澳洲的公司，但凡有点规模的，单元测试、CI/CD这些基础设施必须是有的。自动化测试、单一主线这样实践普及程度都比较高。

第三，对于安全的重视比较突出。这又体现在两个方面，一方面是法律，比如使用的库的License是否合适，是否做了恰当的声明；另一方面是数据，比如使用的数据中有没有PII (Personally Identifiable Information)。当然，后者可能跟我经历的项目偏金融、政府部门有关。

第四，对于Accessibility的重视。澳洲有法律规定哪些网站必须符合WCAG的某一级标准。很多项目都在这方面花了很大的力气。

总的来说，我觉得研发团队国内外的差别不大，这可能也是为什么开发人员来澳洲的比较多，找工作也比较容易。

4. 你为什么创作了ZenUML这个产品？

ZenUML这个产品的历史其实蛮长的。我本身是一个图形控。俗话说一图胜千言嘛。在各种技术图形中我最喜欢的是序列图。

2010年的时候，ThoughtWorks内部有一个前端编程大赛。那个时候，我用纯JS实现了一个基于Canvas的序列图工具。好几个同事都很喜欢那个小工具。我自己也一直使用那个工具。当时也想产品化，但是断断续续，并没有真的做成一个产品。那个时候还是叫做ColorUML，因为我一直想把四色建模的思想融入进去。

2017年的时候，正是国内创业热潮汹涌澎湃的时间。我加入了一个叫做“生财有术”的小密圈（现在叫知识星球了）。收到圈主的启发我开始着手产品化。我用VueJs重写了渲染引擎，然后围绕着这个渲染引擎做了网站、Chrome插件、Atlassian插件、JetBrains插件。

5. ZenUML为使用者提供了哪些特色功能？

很多人跟我说，已经有了PlantUML（或者别的什么工具了），你为什么还要做ZenUML呢？其实很简单，就是那些工具没有解决我要解决的问题。PlantUML也是从文本转图形，ZenUML也是从文本转图形。但是两者的根本区别是，前者描述的是图形，后者描述的是模型。比如下面的PlantUML和ZenUML画出的图是一样的。你单独看代码的话，PlantUML基本上不具有可读性，而ZenUML很容易明白其中的逻辑。

PlantUML

ZenUML

@startuml participant User User->A:MethodA activate A A->B:MethodB activate B deactivate B deactivate A @enduml

@Starter(User)
A.methodA() {
B.methodB()
}

@Starter(User)
A.methodA() {
  B.methodB()
}

其次，ZenUML可以自动的生成符合UML规范的图。UML规范中什么时候使用实线，什么时候使用虚线，什么时候使用实心箭头，什么时候使用空心箭头都是有规定的。但是同时也受到了很多诟病。ZenUML把这些知识自动化了，这样的好处是每个人画出的图都是一致的。

除此之外，ZenUML还支持在图中嵌入Markdown片段。比如下图中用于描述API Endpoint的 POST /orders和任务列表。你甚至可以在序列图中嵌入表格。

下图由以下文本转化而成：

//`POST /orders`
// 
// - [ ] Setup loadbalancer 
// - [x] Config Kong gateway
OrderController.create(payload) {
  // Create an **immutable** `order`
  // 1. Validate `payload`
  // 1. Log with `x-correlationid`
  OrderService.create(payload) {
    // | id | Prod_Name | Price | Inserted_At |
    // |----|-----------|-------|-------------|
    // |123 | book 1    | $10.00| 2020-06-30  |
    OrderRepo.save()
  }
}

第三，ZenUML的生成完全在前端实现。这样不仅速度快，而且保证了用户数据的安全。因为用户的数据不需要传回我们的服务器。这一点在我们实现Atlassian Confluence插件的时候尤其重要。

画图快、修改容易还会带来一个额外的好处就是你可以全身心投入在建模上面而不是繁琐的拖拽。我经常开玩笑说“不要爱上你的图”。

此外，ZenUML的Confluence插件还增加了对MermaidJs的支持，让你方便的在文档中嵌入其他类型的图表。

6. 开发者要提升自己的软件工程能力，你有哪些建议？

软件工程能力是一个非常大的话题。我可以分享两点。

第一，要看到大的图景和远的图景。就像我前面说的，所谓的工程就是让很多人在一起高效的工作。一个人走得快，多个人走得远。如果你看不到大的图景就会觉得有些软件工程是浪费。拿开会来说，很多人都抱怨开会浪费时间。那么是不是就不应该开会了呢？敏捷开发里面有站会、故事卡KickOff、演示、验收、回顾、计划等等一系列会议。如果你是一个人开发这些会议都可以省掉了。但是要一个团队能够以合理的效率协作，这些会议各有自己的价值。文档也是一样，如果你考虑的是明天把代码写完上线就万事大吉了，当然不需要文档。但是如果你一个月之后还会回来维护这个项目，甚至是别人来维护这个项目，文档就是必不可少的。看到大的图景可以帮助我们识别哪些是真正的浪费，哪些是软件工程中必要的投入，进而拥抱软件工程。

第二，工欲善其事，必先利其器。软件工程能力是建立在开发方法之上的，但是同时要落实到工具上面。以文档为例，如果画序列图使用的是Visio，那么你打开的频率低一些是可以想象的。首先你得装了那个软件，还得找到那个文件，再加上修改起来也不是那么方便。使用ZenUML就方便多了，你可以在任何一台电脑上打开浏览器就可以工作了。如果你是在Confluence上写文档就更方便了，你的序列图直接跟文档绑定在一起，而不需要打开另一个工具去画图。

第三，设计观测点。咨询行业讲，没有度量就没有进步。所以不论是自己的软件工程能力，还是团队的软件工程能力，都要设计合理的度量标准。这方面，X-Developer就是一个很好的例子。代码库是团队最核心的交付物。以往基于代码库的度量工具往往是静态的，而X-Developer结合了行业的最佳实践给出了基于提交历史的度量指标。这对于团队衡量自己的工程实践有非常大的价值。

7. 第一次使用X-Developer，感受如何？对X-Developer有什么建议？

我第一次使用X-Developer就觉得非常亲切。我一直希望有一个这样的工具帮助我们分析团队的状态。以往这些工作是基于项目管理工具的，比如Jira。这个时候需要团队成员额外的去更新状态。而基于代码库的分析是自动的，而且数据也更加准确。

目前X-Developer主要是基于提交的历史进行的分析。我觉得未来可以把代码的动态变化加入进来。比如，某个文件中某个时间段被多人修改，这可能会是一个信号说明这个文件的职责不够单一。比如，某两个文件总是被一起修改，这可能是一个信号说明这两个文件耦合的比较紧密。我觉得这方面的分析可以给团队带来更大的价值。