前端小团队如何搞基础设施建设？-低调大师

前端小团队如何搞基础设施建设？

2021-01-13 570

前言

我为什么会思考这个问题？这得从一篇演讲稿说起：

前端搞基建|堂主 - 如何推动前端团队的基础设施建设 - 知乎
https://zhuanlan.zhihu.com/p/148210793

上文最初大概是在2020年4、5月份的时候看到的（当时还是在语雀上，不过现在链接已经失效，好在知乎上面还找得到），作者在上述演讲稿中详尽地介绍了其团队在一年多的时间内如何从零到一构建了庞大的前端基础设施体系，以及这些基础设施到底起到了多大的作用；整篇演讲稿看完真是令人恍然大悟，原来前端可以如此高效以及成体系，看完后我真是对该团队拥有的前端基础设施垂涎三尺，然后臆想了一下在如此高效的前端体系中工作应该是一件很幸福的事情。

不过，考虑到文中这种庞大的、成熟的前端基础设施是建立在庞大的前端团队以及超多的前端业务场景的积累下建设而成的，那么小团队怎么办？

于是很自然地我就想到了这个问题，也在一直试图寻找这个问题的答案；在经过2020年内大半年的在团队内部的基建实践（比较初级）后，我想也许是时候回答和整理这个问题的思路了。

小团队的现实问题

考虑到现实，毕竟大多数前端团队不像大厂那样有丰富的团队人员配置，大多数还是很小的团队，小团队在实施基建时就不可避免的遇到很现实的阻力：

最大的阻力应该就是受限于团队规模小，无法投入较多精力处理作用于直接业务以外的事情
其次应该是团队内部对于基建的必要性和积极性认识不够（够用就行的思想）

小团队基建的必要性

综合上面的现实问题，是否就可以认为前端基建就是大厂/大团队的专属权利和义务呢？毕竟看起来有点无法下手和吃力不讨好的样子；

在我看来，所谓的基建就是一切可以提升编码效率、团队协作效率及业务鲁棒性的工具和方法的集合；只要是项目还在迭代、扩展，就不可避免地遇到新的问题以及效率瓶颈，更不用说很多项目内的业务痛点；目前很多的项目内问题解决路径就是：直到问题出现才会去解决问题（甚至是到问题严重的时候才会去解决问题）；

这就是基建最核心的价值：帮助业务更好的活在未来。^{[参考链接1]}

我很认同上面这句话，基建不仅可以帮助提升当下的效率，还可以避免一些问题的出现，以便业务更好地可持续发展；

小团队应该建设哪些基础设施？

考虑到基建的必要性和小团队的现实问题，我给出的答案是：

优先级：优先发展投入产出比大的地方
范围：着眼于自身业务沉淀及业务需求
自动化程度：量力而行，不要一开始就追求大团队所拥有的成体系的自动化前端基建，推荐“局部研发链路的自动化”

在设计工具的相关交流中，我们还发现了有的团队开始把交互相关的功能也做了进去，例如将页面跳转，后端处理流程逻辑等进行了可视化编辑，自动生成相应的接口和流程代码。这种探索可以概括成：“局部研发链路的自动化”。它是一个初期提效很有用的方法。在对外交流中我们发现了两点有用的建议：

一是任何团队都可以并且也都应该做，不必觉得自己团队研发实力不够，等大公司推出相应方案。局部自动化的关键其实对自己的业务和人员分工的一种总结和思考。在技术上，当自己的业务相对确定时，通过一些简单的方法就能实现。而大公司要考虑的大而全，不一定适合。在人员组织上，几乎所有的自动化方案都有一定的分工要求，这也是因组织而异的。局部的自动化是之后整体架构变革的关键前提。^{[参考链接2]}

投入产出比较大的地方

规范文档：个人觉得规范文档应当是整个基建中的灵魂，因为规范文档可以看做是整个团队的共识，在没有共识的情况下开展基建不免会遇到很多不理解的地方；而且制订相应的规范可以先参考业界常用的，然后再具体讨论内部的细节，花费的时间不需要太多，但是带来的收益绝对是极大的（有效地提升团队协作共识和效率）；
业务（通用）组件：前端项目随着业务扩展，就会自然地抽象出可以被复用的业务组件，这也是一种业务沉淀；不过个人觉得组件的产出流程应该纳入基建中，加以规范和流程化，否则容易造成组件复用率不高、扩展性不强，耦合度过高等问题；
工具函数：实际上跟业务组件类似，只是组件在前端项目内偏向于视图层，而工具函数就是逻辑层，同样地工具函数的产出流程也应当规范化；
代码检测：这个实际上是配合代码规范文档进行的一种辅助手段，因为口说无凭，规范毕竟不是一种实体性质的东西，实际编码过程中可能出现不遵守和遗忘代码规范的情况，如果缺乏一种强制手段来检测规范的执行，那么代码相关的规范约束力就会大打折扣；事实上，如今社区已经存在各种相应成熟的代码检测工具，只需要根据内部约定的规范做一些修改配置就够了；
脚手架：当公司业务项目之间出现高度的相似时，则可以利用脚手架将之前沉淀的项目配置规范化，完成项目创建流程的规范化，可以满足项目快速创建的目的，且项目初始化工作显著减少还可以复用已经沉淀的一些项目配置；

基建实践

说了这么多，那么如何在项目中实施前端基建呢？这里以我在内部的某个项目实践为例：

项目背景：APP配套使用的业务后台；前期工作是从老项目中迁移（重构），后期加入各种新增模块；
项目特点：模块繁多，某些模块功能相似度很高，表单复杂度较大；

上图就是我在项目中大概做的一些基建相关实践的概况；

公共组件产出流程

渲染模型/DSL

其他

解决多分支并行开发公共文件维护的几种方案

基建的效果

团队协作效率提升，规范性明显增强
通过前期组件/公共的积累和沉淀，后续开发速度明显提升（搭积木式开发）
代码复用率明显提高，减少复制粘贴次数

后话

尝试基建可以收获很多

在项目中积极实践/推进基建后我才发现，原来尝试基建可以收获到很多东西：

对前端项目整体会有更深、更本质的认识，能够找出更多的业务及编码痛点
可以拓展提效的更多思路，接触到更多高效的编码体系及工具
可以加强全局观念，认识到各种架构、解决方案的具体适用场景，然后尝试提出更适用于具体业务场景下的架构及解决方案

简言之，积极尝试基建不仅可以对当下项目提效，还能提升自我解决问题的能力；在这不到一年的实践中脑海里已经闪出了各种各样的解决方案，有的是已经应用了，更多的则是还在探索和检验中，总之收获了很多灵感：

一个可行的全路由骨架屏生成方案

基建没有终点

我个人觉得只要是项目还在发展/迭代，基建就没有终点；这一点从大厂的实践来看也是一样的，大厂们正齐步从可视化搭建（半自动化）迈向智能化搭建（全自动化）的探索之路；

相关文档

前端搞基建|堂主 - 如何推动前端团队的基础设施建设 · 语雀
https://www.yuque.com/zaotalk/posts/glkg6d
前端 DSL 实践指南（上）—— 内部 DSL - 知乎
https://zhuanlan.zhihu.com/p/107947462
如何从业务代码中提升技术：使用领域特定语言消除重复代码 - 知乎
https://zhuanlan.zhihu.com/p/38532183
前端搞基建|Scott - 如何在人单力薄时立项推动基建 · 语雀
https://www.yuque.com/zaotalk/posts/oekk3r
前端搞基建|堂主 - 如何推动前端团队的基础设施建设 - 知乎
https://zhuanlan.zhihu.com/p/148210793
长夜未央——企业级研发提效的下一阶段 - 知乎
https://zhuanlan.zhihu.com/p/66474056

本文分享自微信公众号 - 大头兄弟技术团队（bhbdev）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

微信关注我们

原文链接：https://my.oschina.net/bigheadbros/blog/4894082

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

看图学NumPy：掌握n维数组基础知识点，看这一篇就够了

摘要：NumPy是Python的最重要的扩展程序库之一，也是入门机器学习编程的必备工具。国外有位程序员讲NumPy的基本运算以图解的方式写下来，让学习过程变得轻松有趣。 NumPy是Python的最重要的扩展程序库之一，也是入门机器学习编程的必备工具。然而对初学者来说，NumPy的大量运算方法非常难记。最近，国外有位程序员讲NumPy的基本运算以图解的方式写下来，让学习过程变得轻松有趣。在Reddit机器学习社区发布不到半天就收获了500+赞。下面就让我们跟随他的教程一起来学习吧！教程内容分为向量（一维数组）、矩阵（二维数组）、三维与更高维数组3个部分。 Numpy数组与Python列表在介绍正式内容之前，先让我们先来了解一下Numpy数组与Python列表的区别。乍一看，NumPy数组类似于Python列表。它们都可以用作容器，具有获取（getting）和设置（setting）元素以及插入和移除元素的功能。两者有很多相似之处，以下是二者在运算时的一个示例：和Python列表相比，Numpy数组具有以下特点：更紧凑，尤其是在一维以上的维度；向量化操作时比Python...

2021-01-13

456

相信很多 KubeSphere 用户之前都是使用 Jenkins 作为 CI/CD 工具，但是KubeSphere 默认会安装一个新的 Jenkins，无法直接使用已有的作为 CI/CD 引擎。这对于希望能上生产，但是又不方便迁移已有流水线的用户来说，还是有很多不方便的地方。本文的目标，就是给大家提供一个让 KubeSphere 可以使用外置 Jenkins 的方案。限制该方案并不是一个完美的终极方案，因此，在你开始使用外置 Jenkins 之前，请先评估下面的限制： KubeSphere 上已有的流水线将会无法使用如果你已有的 Jenkins 中安装了不兼容的插件，可能会导致部分功能无法使用不会把旧的 Jenkins 上的流水线迁移到 KubeSphere 上鉴于方案可能会有如上所属的风险，请不要直接在你的生产环境上操作！另外，请确保你有一个备份环境，并且在备份环境上进行如下的方案实施。实验环境实验环境： CentOS Linux release 7.9.2009 (Core) 安装依赖： yum update -y && yum install wge...

2021-01-11

580

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。