关于研发体系平台化

nocturne

研发体系中平台化思想是非常泛化和通用的，即便领域跨度如软件领域和硬件领域这么巨大，构建平台时同样是从标准化、通用化、抽象化做起，平台化的源起和发展路径都是形似的。

& ]" j1 y5 b  p" ]0 s, T2 o·  什么是平台  

/ P$ a6 N) q2 ^, l, o" `    业务不断膨胀，对人力的需求构成和业务数量的线性关系，需要寻找一种方法打破这种关系，让更少的人力支撑更多的业务，这时就要找到共性，进行抽象和复用；为了让产品、业务竞争力不断提升，需要将良好的技术实践作为积累沉淀下来，逐步建立技术壁垒，这两类是所有平台被建立的初衷，也是它们的目标：提高研发效率和增强技术竞争力。

, U8 m. O% b, X! f. C7 f' H; `    对平台化的关注不能仅仅看开发部分，还应该关注前端的需求、设计、后期的运维等各方面，不能拒绝客户的高度定制化需求，甚至应该考虑平台能力成熟稳定后，构建一系列的工具，实现业务逻辑的自动化、辅助化构建。结合任一平台刚刚开始的起点，往往只是对某一类业务的开发做了规范化、标准化的定义，我们可以看到，架构师应该关注的平台，不应该仅限于那个实现级别的技术平台，而是基于领域目标的整体考量，是全过程的、全链路的工程化实践体系。
  x7 D  s2 F' H9 n- W* \$ `
7 d6 f6 L" a9 g5 `! @    所以，在现阶段，我们可以对平台下个初步的定义： 平台是为了降低业务实现中的重复劳动，复用既有的技术实践经验，提升产品、业务开发效率与质量，允许研发团队将更多精力用于技术提升和技术创新的一整套规范标准、设计原则、技术实现与工具的集合 。

·  平台的属性与粒度划分

    平台是在研发活动中生长起来的，是一个技术领域的产物，我们面向业务，但需要将业务看作长在平台上的内容，而非平台本身。我们可以大体清晰地看到有两大类的平台属性：

( z) m% y7 `" S    一类是为了快速构建多形态产品和业务搭建的 产品支撑型平台 ，例如某嵌入式系统为了不同产品构建统一的操作系统，实现基础能力复用，为具体业务逻辑提供容器；又如某应用研发平台，可以为各垂直业务提供开发支撑，同时允许各级别的开发活动在其上建设业务。
  F. n& U+ @( f! ?
    一类是为了建设横跨多产品、业务的 能力型平台 ，例如扫码技术平台，结合模组设计、算法，可以被多类产品集成并使用，同时在性能和性价比上不断优化改进；又如流媒体技术平台，对未来多类产品的音视频采集、编码、存储、传输与投放做统一设计，赋能这些产品。
8 e6 I; @) O4 r
    但我们日常工作中为了支撑多产品开发或者增强产品能力所做的工作很多，并不是所有工作就可以叫做干了一个平台出来，我们对于平台的基本粒度应该有个定义。
) `* m9 r" I2 j- n; Z3 f
    在我们现有的例子中，已经有平台是横跨多个技术领域的了，比如一个扫码组件技术平台就可以横跨硬件设计、嵌入式、软件算法等多个技术领域，所以并不能按照技术领域来对平台做粒度的划分。我们观察大多数被分享出来的平台，都具备一个特征，就是： 该平台的产物可以支撑或者被集成于多个产品和业务，并形成完整的用户产品 。也就是说， 平台的基本粒度是除了用户业务逻辑外，完成了完整的自底向上的系统搭建，达到这样的构建水平，方可称之为平台 。通常一个平台具备其基础层、能力层的内容，根据不同的业务需要，可能会有协议层、模型层、组件层、工具层等层次或者外围工具。

1 w2 r, F7 l! \. v. h7 i    当然，随着业务的跨度增大，平台也有大小之分。若干个平台可以组成一个为更大业务服务的平台，甚至整个公司的产研组织，都可以被当做一个大平台。这就需要我们对粒度进行进一步的划分，根据我们的整体规模和管理需要，慢慢形成几条主线进行规划。而平台架构的思想，则是所有日常开发中都应该被用到的。
% s7 H. e8 l# n% O# @2 w. x& ]
9 T! e, m+ ?+ \9 i8 k·  如何构建平台

4 N! p+ D4 ?/ O& c; y6 m$ M, i    不同软件领域，软、硬、测领域的平台化构建过程都具备相似性，简而言之是不断 抽象总结 、 固化模式 、 提升固定模式化开发效率 的过程。

9 J: v  N* V$ b! Q$ v    抽象的第一步是落实开发规范，规范本身即是一种共性抽象和显性固化的过程。进而可以将功能/业务边界清楚的部分进行模组的划分，对模组进行分类于是形成了分层设计，为了让不同层不同模组间的互相通信和调用也规范化，则建立了信息传递的通信标准。这一步构成了基本粒度的平台落成。
9 X0 [. A1 S8 M; N4 c8 A; C% f
    为了让平台发挥出它应该有的效率优势，会固化其上的一些设计空间。平台的搭建，从某种意义上来说，就是将良好的、被证明行之有效的实践复用起来，将寻找更先进的方式方法的工作，留给少数架构师和工程师去做，证明有效了再采纳进来。所以工程开发中，才真正省掉了一些会被重复做的开发量。甚至为了保证经验不足的工程师不捣乱，平台中的部分模组实现细节是信息受控的，并不允许被随意查看修改。这种固化模式的动作，需要落到对开发工作中真正工作量的关键路径上进行衡量，解决关键路径的瓶颈，做到可量化的展现平台效率。同时，它也将工程师的成长，从大量实践，引导到对优秀设计的参考学习上。此处仍旧需要考虑平台的开放性，一是不要过于约束优秀工程师的能力，平台的模组是否容易被自行开发的模组替换，二是平台负责的架构师，是否具备不断观察同领域领先实践的精神，来促成平台向更佳设计演进。
" H8 j$ c& o' b% O# g, k+ q0 _; N
+ J; v! s7 m" ?- G' i    如果要进一步挖掘平台的效率能力，那么就要开始考虑如何让机器帮助工程师做更多的事情，这时候要去建立业务内容层面的抽象辅助工具，一是让机器帮助工程师去自动化产生业务逻辑，二是扩大可参与开发的工程师人群范围或者说降低对工程师的专业技术要求，形成人力的灵活使用。我们谈论的No-Code、Low-Code，本身是基于对业务逻辑如何产生的通用模型进行了抽象，并且视图化了工具做到的。平台建设是否要达到这个层面，要看业务的规模和价值，当业务存在大规模、高价值、充分多样性的前提，如此的建设才能发挥其优势，所以对架构师而言，心中合适的价值平衡，也是一个迈向高阶的必备素质。

·  衡量平台的标准
) s* m' I0 n# h- ?) D+ \/ w/ K
7 }3 a9 @5 }4 k9 m3 o必要性 ：

8 j' ~' K  ?$ Y- M4 f& }6 i7 s    即这个业务和技术领域，有没有建设平台或者说建设到这个程度的平台的必要性。我们必须明白，优秀的架构师不是去做一个极致领先的设计，而是去做一个极致合适的设计，有些业务刚刚发生，运用平台化架构思想做设计是天然的，但并不构成一个平台属性，也未见得有必要建立起一个覆盖全链路的平台。
5 N# u" r. i  H8 ^! u2 v
    平台需要明确其面向的业务和属性，原先业务的痛点和关键路径是什么，是否平台化可以解决，平台要可以准确描述其上承载的业务规模以及带来的效率优化点。
# J& S1 n3 x$ D; u
全链路 ：
: U6 V) X3 Y. E. c8 Y
    平台并不止技术架构设计本身，是产品/业务实现的完整链路闭环。建设一个平台试图解决一些问题，也很可能带入新的问题。
; l& c5 a  X2 |3 j* t% R
) y+ p! f: J$ a1 x    考察一个平台，同时也需要对平台在全链路的各个环节提供的方法、工具进行考察，确认整体对效率有益，而不是产生了新的障碍点。

# M5 y0 N+ a7 G8 l1 i8 m% [1 I可量化 ：
* n# I1 T* e# ~6 A/ ~
7 ?! W& |$ }1 B: U. c( ^  ^. a% @    平台面向的业务目标，一定是有关键路径的，对任何关键路径，我们都可以建立量化关键路径的方式方法。平台的有效性证明，也来自对关键路径的不断测量，量化展现。
: u6 E. ?% x$ E, N- A+ e( G

qian211111

研发平台体系化是很有必要的一项发展，这样才能更方便管理工作和研发的后续

purpose_857

平台并不止技术架构设计本身，是产品/业务实现的完整链路闭环。