在过去的一段时间里，我一直在为公司建设平台级的产品。我所在的团队负责的一款低代码页面搭建平台目前支撑了全公司近150条业务线，产出了数千个页面。本文将以此项目作为切入点，谈一谈自已关于平台建设的一些想法。
做好平台的角色
在做任何一个平台之前，我觉得，都非常有必要一直问自己，这个平台的用户是谁，能解决什么问题，为什么不用xxx（xxx包含但不限于公司内部的其他平台、开源方案、商业成熟方案）。并以此来作为建设平台的根基，如果这几个问题都不能很好的回答你建设平台的意义，我觉得应该考虑一下这个平台是否具有必要性，或者适当调整平台的方向。
通用平台和一般的业务有一个很大的区别在于，业务往往只对特定的产品线负责，而平台提供的是通用能力，不局限于特定的业务线，不局限于特定的功能。二者关注点不一样，此处不再细表。
正是因为如此，所以我觉得平台的建设非常重要的点在于 搞清楚自己的定位，并且在产品的迭代开发宣发运营中始终如一地坚持自己的定位。坚持自己永远是 “平台”，而不是 “业务”，对内的迭代开发要注重需求的抽象和通用性设计，对外要摈弃做业务的工具人，而是要做业务的协助者。
以低代码平台为例，我觉得首先就要明确平台是做什么页面的低代码，因为不同的目标产物对于平台的要求不一样。比如如果搭建的页面是活动页，那么搭建的重点在于UI的还原和交互设计上。而如果是做中后台页面的搭建，那么中后台页面的痛点就在于数据流和大量的表单，以及和后端的协作，对于UI上没有非常精细的要求。
其次，要明确，哪些是平台要做的，哪些是平台不做的。这点其实非常非常难，我看到很多平台的owner由于掌握不好这一点，所有业务方提的需求都一股脑地不假思索地支持，美其名曰赋能业务。但其实平台已经承担了它不应该承当的复杂度。在软件设计中，可能我们可以用不高的复杂度去覆盖 80-90%的场景，但是如果要支持到 95%的场景，我们投入的人力可能要多倍；如果要支持到99%的场景，那么需要付出里的人力和支持到80，90%的复杂度已经不是一个量级了。而且还有一个需要注意的是，投入开发人力并不是开发的终点，后期还有维护成本，为了覆盖这些场景，系统的复杂度会上升很多，越复杂的系统，越是有可能导致牵一发而动全身，后期优化的历史包袱会越来越重。
因此，在实际工作和开发中，一定要和主管部门和业务部门充分沟通，搞清楚平台的定位，不要一股脑儿的抗下所有需求；要考虑维护人力，不要寄希望于将自己的平台做到覆盖所有的场景，而是将自己目标场景的问题都漂漂亮亮地解决。
平台的演进
- 调研：搞清楚要解决什么问题之后，看看市场上有没有成熟的方案或者开源的方案，自己的平台定位和这些现有平台的区别。
- 实现一个mvp（Minimum viable product 最简可行产品）版本：验证可行性
- 内部试用：可以现在内部一些简单的业务中进行试点，主要是为了验证平台是否能不能覆盖最基础的场景
- 内部承接业务：尝试承接内部整块业务，整块业务往往会包含各种各样的场景，此时可以对平台缺乏的能力进行补充，也可以从内部反馈出发，对平台功能进行迭代优化
- 验证效果：平台承接业务之后，我们有必要对相关的数据进行采集分析。节省了多少资源，带宽，人力，优化了多少时间等等
- 推广运营：可以向部门内的其他组甚至跨部门的同事宣发推荐。这里一定要注意，和平台能力同等重要的是平台的售后服务，只有让用户没有后顾之忧，才愿意在平台上投入精力，平台工作也一定要将售后纳入计划。
- 业务支撑：业务需求是复杂的，平台往往需要一段时间去适应这些业务，此时需要平台的开发同学去帮助业务部门落地各种各样的业务需求。
平台的进阶
以低代码平台为例，我们在很长一段时间里，工作的中心都是帮助业务方落地业务，这个过程中，我们提供的支持包含了以下两个方面
- 帮助业务方搭建页面
- 帮助业务方开发各种定制化的组件，以满足业务方的需求
这个过程，我们弱化了平台的角色，更多地是做业务支持部门，帮助业务方落地各个业务。在这个过程中，我们和很多部门的同事建立了非常深的信任。业务部门也愿意相信我们的平台确实能够帮助他们节省人力，提高人效。很多业务部门的同学也逐渐开始学习如何使用我们的平台，实现他们的需求了。
慢慢地，我发现，越来越多的部门可以自己完全cover住自己的需求，而且需要我们定制开发的组件也越来越少。换句话说，平台需要做的工作越来越少了，当时我们有同事就说了，好像事情越来越少了，大部分的页面都不需要我们帮助搭建了。作为平台方，这可真是让人欢喜让人忧。
也就是在这个时候，我觉得是时候调整以下产品重心，平台的工作重心由业务支撑转移到平台迭代。
我首先规划了一次代码的重构，为什么要在这个时候重构呢，原因有以下几点
- 业务形态逐渐稳定；比如早期我们做了很多业务上的尝试，这里有大部分已经被后续更优秀的方案取代了，这类兼容性处理逻辑可以优化掉
- 代码复杂度与其承当地职能不匹配：原因是在比较长一段时间的业务支持中，很多水平不一的同事参与开发，导致代码逻辑非常散乱
我们的平台是一个React项目，具体的表现在
- 大量无效的re-render导致在一些极端场景中，很容易出现闪屏
- 想要对平台加新的功能，非常非常困难
在这个背景下，我组织安排了一次对代码的重构，重构的核心是优化代码可靠性，稳定性，可维护性。具体的细节本文不再表述。这次重构是平台转型的起点，也是平台迭代的基础。也意味着平台方向由短平快的业务支撑转向建设通用的平台能力。
在转型之后，很多同学搞不清楚自己要做什么，因为之前是业务部门向我们提需，我们评审过后，稍微优化一下，就可以做到系统中去。但是平台化之后，我们是不能继续使用这种思维，而是要以一个平台的角色去思考业务的需求。
大概的流程是 ![./process.png]
可以看到，在用户提出需求，平台侧会对需求进行提炼，这个步骤是平台化演进的关键。如何将需求提炼是核心，大概的思路就是，将具体需求进行抽象，抽象成不仅仅可以服务于单独某一个业务，某一个场景的能力。
以多语言能力为例，在过去，我们做业务支持的时候，我们会为开发一个多语言组件，配置一些属性，比如说i18n接口地址，参数之类的。业务方需要多语言能力的时候，只需要把多语言组件拖入页面中，该页面就有了多语言能力。而在平台化建设中，同样的需求，我们首先要对这个进行提炼，确定什么样的场景需求多语言切换，有没有必要每个页面都放一个多语言切换的组件，如何动态配置多语言映射，如何扩展多语言能力。在经过这样一系列思考之后，我们对多语言进行了重做，将多语言能力集成进入应用中，会固定现实在应用顶部。我们和公司现有的多语言平台进行合作，站在巨人的肩膀上，避免重复建设。在使用上，只需要在配置上配置一个字段就可以拥有多语言能力。
再举一个例子，有一次，一个业务平台的研发找到我，跟我说，他们的业务平台迭代很快，他们每一次上线一个重要的功能都需要开发去各个用户群里公告一句。这个过程非常低效，他提出的方案是希望我们能够在页面配置中加一个web hook，这样结合企业微信的机器人，可以实现每次更新都能及时通知用户。当我接受到这样的需求的时候，我没有按照需求来实现，原因在于，1. 更新机器人需要额外的设置，放到各个群里。每次更新，机器人会通知群里的所有人，但是并不是群里的每个人都关心这次更新，而且这种更新机器人的消息很容易导致群友屏蔽群消息，这将大大降低消息的传达效率。2. 很难跟用户描述清楚，更新了什么，需要注意什么，也就是消息不完整。提炼需求之后，我提出了这样的方案，首先会通过轮询来查询页面的版本信息，如果有更新，则提示用户进行刷新，为了降低服务端负载压力，轮询会在切出页面或者深夜的时候停止。还提供了一块公告区，通过非常显眼的样式，传达此次更新包含了哪些内容，用户可以在发版的时候填上。当我将整理好的方案跟业务方进行确认时，业务方对效果也非常满意。后续我们将此能力内置在页面和应用中，无论是页面更新了还是应用更新了，正在使用系统的用户都会得到通知。
以上只是平台迭代的冰上一角，在长期的实践中，我觉得平台的迭代方向可以从以下几个地方得到
- 从业内的实践中来，对于低代码平台而言就是业内的低代码平台拥有什么能力，我们能不能支持
- 从你的用户反馈中提炼而来
- 从不用你平台的用户反馈提炼，搞清楚为什么不用，它们有什么痛点，多研究有什么解决方向
- 从日常的使用场景中抽象
除了平台的迭代方向，平台发展的另外一个方面就是做平台的扩展性设计。前文我们说到平台核心不要做的太过于厚重，那样会导致平台变得难以维护，那当我们平台无法满足业务需求的时候，我们可以通过对外开放扩展能力来支持这些业务。这里不表述具体的细节，仅提两个关键点
- 外部依赖运行在沙盒中。在做扩展性设计的时候，一定要注意，要假设所有的外部依赖均不可靠，所以要将这些依赖运行在沙盒环境，不要让其影响系统核心的正常运行。这其实也叫 鲁棒性
- 要保证外部依赖和内部核心是独立分开的。这其实也是业务开发和平台开发的区别，如果每次外部依赖发生变化，内部核心都要做调整，那是不合理的。这其实是 计算机科学里的 开闭原则
平台运营
平台建设除了平台的开发之外，还有一个非常重要的部分就是平台运营。因为平台产品往往和独立产品比较类似，和业务开发很大的不一样在于，我们需要自己运营自己的产品。这里谈几个小点
- 建立反馈渠道
对目标用户建立起良好的反馈渠道，用户的反馈是我们平台建设的风向标。很多时候，往往平台的开发同学觉得做得非常好，但是最终的用户往往并不这么觉得，这会经常出现在一些过度设计的功能上。此时就需要平台的开发同学有很好的产品 sense，简单好用的功能才是用户最希望看到的。当然，反馈还包含平台的客服工作，做一个平台，其实就像你卖给客户一个电视，这个电视肯定不是用一个月两个月就会换的，良好的售后保障会大大 增加用户选择你的可能。对于平台工作而言，客服工作就是售后服务，平台方要做业务方最坚强的后盾，让他们没有后顾之忧。对于日常的问题要做好记录，定期梳理。在我们的项目中，我们后续还做了一个人工智能客服机器人来帮助用户解决日常问题。
- 定期向用户汇报
不知道大家有没有这种感觉，每次看到手机系统弹更新提示，就会觉得，这家手机厂商还没有抛弃老用户，还是挺负责的。相反，如果一个手机系统，几年不更新，你可能会想，这厂商这么快就把老用户抛弃了，这就不更新了，那我系统没有新功能了，没有安全修复了，下次再也不买这牌子的手机了。
同理，平台建设也是一样的道理，很多平台的功能其实并不会直接影响到用户，但是还是要记得定期向用户通报平台最近的迭代，这样，用户会觉得这是一个一直在改进优化的平台。可以建立用户和平台之间的信任。
- 文档建设
前文提到平台其实更像是一个独立产品，文档建设是重中之重，良好的文档可以提升用户使用的信心，还可以帮助用户更好地使用平台。