十倍效能提升——Web 基础研发体系的建立

互联网渗入到各行各业业务爆发企业竞争白热化对速度和品质要求越来越高一线工程师队伍越来越庞大管理成本增高这样的多重背景下除了底层核心技术外一线 web 研发效能的问题也逐渐成为决胜战场的重要因素。然而在现实中我们看到因为一线的研发工作可替换性强所以并没有受到足够的重视同时也缺少更统一、更有深度的规划和管理。实际上将一线工程师所直接接触到的应用框架、测试、部署、监控等领域作为一个完整的体系来思考并打造成一体化的基础设施能为企业的业务研发带来巨大的效能提升。在《月相》一章中我们将介绍Web 基础研发体系有哪些构成部分并且将深入到关键性的技术和问题中。《潮汐》一章将介绍如何配合这套研发体系在组织结构上做出一些调整通过管理手段进一步挖掘团队潜力打造更高效的组织。另外希望这些内容也能为一线工程师提供一些职业规划上的引导。2 月相我们将要讨论的研发体系涵盖了”研发流程“和”系统“两个维度。可以用一张大图来描绘可以看到将这些内容作为一个整体符合目前互联网公司”核心技术“ ”web 研发能力“ 的模式能快速产出应用。其中”用户“、”权限“、”流程“可以说是绝大部分系统的铁三角因此我们也划入到了基础研发体系中。接下来看每个部分。从流程的角度来说提升效能的关键在于”工具化“和”自动化“我们就以这两点来切入。2.1 设计首先是设计设计与编码的结合是目前业界想象空间最大但也是最不成熟的领域。对于自动化的实现目前的尝试大致可以归纳成两类第一类与设计师约定规则按规则转化设计稿。这种方式的关键在于“既要规则简单易于被设计师接受又要保证视觉上的关系能完整转化成程序中的关系“。我们举个例子来说明”视觉上的关系“和”常见的程序中的关系“: 网页上这样一个场景可以很容易地理解为一个 Tab 组件里面嵌着一个按钮他们是”嵌套关系“在程序中用 html 可能这样写:Tabs Tabs.Pane titletab1 Button/ /Tabs.Pane Tabs.Pane titletab2 / /Tab但是在现代的设计工具中图层信息表示的仅仅是视觉上的前后关系。这就出现了一种不匹配设计师可以通过一万种方式来表达同样的视觉效果。因此要保证正确识别关系必须和设计师约定只能以某种方式来创建图层。但问题是这种约定本身对设计师来说没有实际意义对他来说只是约束。除了嵌套关系以外位置关系也是同样的问题——目前设计工具产出的设计稿只是某一种具体尺寸的视觉效果而我们实际产品的尺寸会因设备不同而不同的甚至可以随着浏览器窗口的缩放等功能动态变化怎么来表示这种变化对设计师来说也是额外的约束。乐观的是从技术角度来说总归是可实施的。第二类尝试像游戏一样做专用的设计工具则从根本上解决了上述问题。(React Studio)思路很简单既然设计师能有多种方式来表达那么我们从工具角度来约束是不是就不会有问题了虽然同样有约束但是对设计师来说负担要小多了不需要额外记忆按照工具的指引使用即可。我们甚至还可以提供一些高级功能防止出现一些人为错误以此来吸引设计师。这种方式唯一的缺点是有一次性的学习成本。虽然目前的自动化方案都还只是从“视觉稿”到“程序静态视图”的自动化并不包括交互逻辑的自动化但已经有了巨大的意义。在前端程序员工作的统计中发现他们有一半以上的时间都是在”调整大小、调整位置、对像素、对色值“而且越是好的前端这个时间比例越大。因为写逻辑是可以通过提升自身素质实现量级缩小的而写样式这个工作本身很难实现量级的时间缩短。如果在研发体系中设计稿能自动转化成可用的代码无疑对传统的 web 页面研发会有巨大的提升。虽然做专用工具看起来应该是最终的方向但在目前的现实环境中可能会因为加重设计师的使用负担而被抵制所以通过在原有设计工具上做约定的方式来过渡可能更合适。在用约定的方案里怎样让约定即不给设计师造成太大的负担又能解决上述的规则转化问题就成了重点。在实践中的解法是通过工具的高级能力来补偿设计师。这部分细节已在《设计稿自动生成可用页面的展望》中详细描述过这里不再赘述。2.2 研发、测试和监控我们将这三个环节合在一起来讨论是因为他们存在技术决策上的上下游关系。过去在大团队中规划研发体系常常会出现一种现象就是研发、测试、监控都是由不同团队规划的而每个团队都想着做平台。后来慢慢发现这个思路是有问题的因为做平台必然要考虑到不同端的接入要花成本将自己的服务抽象得足够底层花成本对不同的端做适配。而在这三个环节中研发中的运行时框架(应用框架)是工具化和自动化的核心只要对运行时框架多进行一点点投入后面测试、反馈、监控的研发成本就能降到非常低举个前端的例子。在搭建可视化页面搭建平台时我们设计了一个将“所有组件数据都统一到一棵树”上的方案。在传统的 React 中所有组件的 state 和 props 合起来才能表达一个页面唯一的状态state 和 props 分散在组件中不易收集。而在这个设计中全局的 state tree 即表达了页面的一个状态如果将每一次变化后的state tree 都存起来即可通过回放来展现页面动态变化的过程。更进一步的是利用这个特性我们在 200 行代码之内就实现了“录制即测试用例”的功能。用户无需写任何晦涩的用例代码在调试自己写的页面时只要觉得没问题就可以将刚才的调试过程保存成一个用例。再举一个接口层的例子。我们运行时框架的接口采用了 GraphQL 并且告别了手动写接口的形式全部利用视图勾选生成。这解决了两个研发中常见的问题杜绝了手工约定接口时可能出现的拼写等错误。能自动统计到所有对某一接口进行消费的页面一旦接口进行调整可以自动通知到下游甚至能自动生成适配代码不影响下游。这也就极大地减轻了测试环节的压力。之前的思路基本都是通过扫描代码去发现接口错误要消耗大量资源现在看起来没必要了。这两个例子都是从研发的角度来思考所看到的收益我们再单独从测试与监控的角度来看。测试领域有一个热点—— UI 自动化。目前的 UI 自动化有两种方案图片对比 与 dom 树对比。