Open yanyue404 opened 3 weeks ago
https://kongwutw.github.io/blog/tech/base.html
如果说写代码是低头走路，那么学习不同团队的基建思路就是仰望星空，让我们在高速发展的前端的道路上不至于迷失方向。
基建的内容这个话题其实可大可小，不同的团队规模有不同理解，不同的公司规模也会有不同的要求。
以上所有的功能有些做出来就是可视化的，有些用脚本就可以跑，当团队规模足够大的时候，是需要做可视化工具的，让大家可以更直观的使用所有的功能。
不同的团队规模、不同的团队水平和不同的业务体量决定了基建在这个团队中的意义，脱离以上三点实际情况谈基建是没有任何意义的析。
前面说过脱离实际情况谈基建是没有任何意义的。基建需要从问题出发做事情，跟随团队一起成长。
这个时期的团队规模一般都在 1-3 人左右，，具体数字完全靠自己估计，不要深究合理性。可能公司也是发展的早期，整个技术部或许也就 20 人以内。业务量来说，可能有一款核心的产品，两个粗糙的运营工具，三四个辅助的项目支撑业务。我通常会认为这个阶段是不需要一步到位做基建的。
首先要做的是代码层面的规范，能初步确保代码质量过硬就好了，需要 leader 经常抽出时间做代码 review，帮助小伙伴们提高代码的质量，严把质量关。其次可以做一些简单的代码规范文档，项目中融入一些业务说明文档，没有能力构建可视化发版工具的可以考虑用脚本发版，毕竟脚本发版并不见得有多低级。可视化和工程化构建不也是建立在脚本之上么，这个无可厚非。
反过来说，你花了大量的人力资源，协调了多个部门终于做了可视化建设和工程建设，但是公司迟迟不做新项目，业务量迟迟不增加，其实有点大材小用了，对业务的提效并不明显，得不偿失。不过，对个人来说这个阶段做基建是提升个人能力的关键时期，个人能力必将会有大幅度提高，为以后应对公司腾飞打下坚实的基础。
这个时期的团队一般会在 4-8 人左右吧，具体数字完全靠自己估计，不要深究合理性。公司业务也会以亿为规模计算，公司人数在 100-500 左右。涉及到的各种 toB 项目和 toC 项目会有几十个。这个阶段的团队应该已经在早期沉淀了一些东西，也算是有家底的团队了。
这个时候的团队为了支撑不算海量的业务，会去有意识的尝试使用不同的工具，助力业务开发。同时，大家也会发现不同技术栈带来的理解成本和开发成本剧增，是时候要进行技术栈的统一了，团队里应该会有一些大牛，积极推进工程化建设，组件建设初具规模，抽象出来的工具库初步具备体系，开始考虑搭建私有的 npm 仓库，开始考虑完善相关的的技术文档，甚至开始考虑做一个专门的网站承载一些文档，帮助团队成员开发速查，帮助新人尽快了解团队整体技术水平。
同时，开始用 gitlab/CL/CD 或者 jenkins 来做自动化建设，解放人力。项目越来越多，线上代码异常难以定位，总是花费大量人力维护老项目也力不从心，这时候你会想着去做一些监控的事情，帮助团队发现代码中的问题，提高代码的健壮性。leader 会有意识的推动各种组件和工具的 npm 化，方便后期维护，同事也可以极大提高开发效率，保障代码质量。
罗马不是一天建成的，这个时期对团队转型来说，对喜欢的人来说充满了刺激，对不喜欢的人来说可能就是噩梦，在打破惯性思维的道路上，必定会遇到阻力，推进工具时代的发展必定会耗费大量的心力，但是收益也是巨大的。
这个时期的团队一般会在 10-30 人左右，具体数字全靠自己估计，不要深究合理性。公司业务会以十亿规模计算，公司人数可能在 500 人-1000 人左右。涉及的应用应该在上百个左右。当然也不乏提前布局的 leader，在业务量没达到这个规模的时候就做了工程化的建设。
这个时候的团队应该会有一些资深大牛，他们对业务有深入的了解，能够左右业务的决策，能够把控项目的进度，同时避免一些雷区。团队的技术生态应该是百花齐放的，同时内部以小组为单位实现技术栈的统一。对于一些普适性和高频的业务逻辑应该可以实现 api 化，通过调相应的业务组件或者相应的功能性文件包实现快速开发。作为一线的程序员只需要去关注具体的业务逻辑，不需要去关注具体的技术细节。
在海量技术文档的帮助下，即使是新来的员工，也能快速完成开发。运营通过可视化的开发平台，可以实现组件的拼装，从而完成功能开发，通过一键发版，进行测试和上线，程序员在这里起到辅助的作用。这个时候的基础架构应该已经有很多的积累，大多数项目都可以实现拿来即用的程度。箱子里的工具多了，做什么都比较顺手。前端从造工具进入用工具的阶段。
这个时期的前端团队规模应该在 50 人以上，具体数字全靠自己估计，不要深究合理性。公司业务会以千亿规模计算，公司人说会在 1000-100000 之间。涉及的应用可能没有一个人真正的去统计过，因为实在太多了。
这个阶段的一些 leader 或者资深技术可能需要进入深度的商业发现或者商业决策。基础设置除了上面的拿来即用，更多的是实现智能化，设计的东西能通过智能化迅速转化为代码。运营不需要再盯着前端写代码，因为他们通过可视化界面已经可以自己完成功能的开发和上线。
这个阶段的团队不仅有大量的工具，还有大量的物料，通过智能化的方法实现无感开发。这些技术实现不仅影响到公司的技术发展，而且影响到整个行业的生态。我们期待这个时代的到来。
有的公司有专门做基建的团队，比如架构组，运维组之类的部门；有些公司的程序员是一边做基建一边开发业务代码。这是两种不同的组织形式，没有好坏之分，只有是否适合的区别，当然其中也会涉及到一些行政干预的力量。
不同的公司可以根据不同的情况进行设计。以上两种组织形式，归根到底都是为了解决一个问题：怎样找到合适的人去做合适的事？
以上根据基建的点选择不同技术栈的同学来做。
基建工作的落地实施除了需要技术的热情，同样离不开公司 CTO 甚至是大 Boss 的支持，要多学会用数据说话，通过数据和收益来证明一件事情的必要性和可行性。这是前提，缺乏这个前提你做的事情可能并不会得到各方面的支持。
同时，基建工作的落地和选的人有密不可分的关系。如果在一开始做的时候就没选好人，那么基建的效果可能会大打折扣，甚至做出来的东西根本没人用，以至于后期没人维护没人管。
另外要做好数据统计工作，做出的东西在交付使用之前尽量做好使用量统计工作。比如，可以统计一个组件库在整个前端团队的引用次数有多少，一个工具的打开率有多高，节省了多少的人力成本，节省了多少的时间。
这些东西如果能有可视化的界面做支撑，下次再做基建立项的时候，被领导信任的概率就会大大增加。
如果说写代码是低头走路，那么学习不同团队的基建思路就是仰望星空，让我们在高速发展的前端的道路上不至于迷失方向。
一、基建工作都有哪些内容
基建的内容这个话题其实可大可小，不同的团队规模有不同理解，不同的公司规模也会有不同的要求。
代码层面
发版规范
开发规范
工程化和组件化
统计监控
安全防控
文档沉淀
可视化搭建
以上所有的功能有些做出来就是可视化的，有些用脚本就可以跑，当团队规模足够大的时候，是需要做可视化工具的，让大家可以更直观的使用所有的功能。
二、基建的意义何在---为了解决什么问题
不同的团队规模、不同的团队水平和不同的业务体量决定了基建在这个团队中的意义，脱离以上三点实际情况谈基建是没有任何意义的析。
解决业务问题（也是最核心最基础的问题）
实现团队练兵
梯队建设
影响力建设
三、不同团队的发展阶段以及基建的侧重点分析
前面说过脱离实际情况谈基建是没有任何意义的。基建需要从问题出发做事情，跟随团队一起成长。
上古时代
这个时期的团队规模一般都在 1-3 人左右，，具体数字完全靠自己估计，不要深究合理性。可能公司也是发展的早期，整个技术部或许也就 20 人以内。业务量来说，可能有一款核心的产品，两个粗糙的运营工具，三四个辅助的项目支撑业务。我通常会认为这个阶段是不需要一步到位做基建的。
首先要做的是代码层面的规范，能初步确保代码质量过硬就好了，需要 leader 经常抽出时间做代码 review，帮助小伙伴们提高代码的质量，严把质量关。其次可以做一些简单的代码规范文档，项目中融入一些业务说明文档，没有能力构建可视化发版工具的可以考虑用脚本发版，毕竟脚本发版并不见得有多低级。可视化和工程化构建不也是建立在脚本之上么，这个无可厚非。
反过来说，你花了大量的人力资源，协调了多个部门终于做了可视化建设和工程建设，但是公司迟迟不做新项目，业务量迟迟不增加，其实有点大材小用了，对业务的提效并不明显，得不偿失。不过，对个人来说这个阶段做基建是提升个人能力的关键时期，个人能力必将会有大幅度提高，为以后应对公司腾飞打下坚实的基础。
工具时代
这个时期的团队一般会在 4-8 人左右吧，具体数字完全靠自己估计，不要深究合理性。公司业务也会以亿为规模计算，公司人数在 100-500 左右。涉及到的各种 toB 项目和 toC 项目会有几十个。这个阶段的团队应该已经在早期沉淀了一些东西，也算是有家底的团队了。
这个时候的团队为了支撑不算海量的业务，会去有意识的尝试使用不同的工具，助力业务开发。同时，大家也会发现不同技术栈带来的理解成本和开发成本剧增，是时候要进行技术栈的统一了，团队里应该会有一些大牛，积极推进工程化建设，组件建设初具规模，抽象出来的工具库初步具备体系，开始考虑搭建私有的 npm 仓库，开始考虑完善相关的的技术文档，甚至开始考虑做一个专门的网站承载一些文档，帮助团队成员开发速查，帮助新人尽快了解团队整体技术水平。
同时，开始用 gitlab/CL/CD 或者 jenkins 来做自动化建设，解放人力。项目越来越多，线上代码异常难以定位，总是花费大量人力维护老项目也力不从心，这时候你会想着去做一些监控的事情，帮助团队发现代码中的问题，提高代码的健壮性。leader 会有意识的推动各种组件和工具的 npm 化，方便后期维护，同事也可以极大提高开发效率，保障代码质量。
罗马不是一天建成的，这个时期对团队转型来说，对喜欢的人来说充满了刺激，对不喜欢的人来说可能就是噩梦，在打破惯性思维的道路上，必定会遇到阻力，推进工具时代的发展必定会耗费大量的心力，但是收益也是巨大的。
工程时代
这个时期的团队一般会在 10-30 人左右，具体数字全靠自己估计，不要深究合理性。公司业务会以十亿规模计算，公司人数可能在 500 人-1000 人左右。涉及的应用应该在上百个左右。当然也不乏提前布局的 leader，在业务量没达到这个规模的时候就做了工程化的建设。
这个时候的团队应该会有一些资深大牛，他们对业务有深入的了解，能够左右业务的决策，能够把控项目的进度，同时避免一些雷区。团队的技术生态应该是百花齐放的，同时内部以小组为单位实现技术栈的统一。对于一些普适性和高频的业务逻辑应该可以实现 api 化，通过调相应的业务组件或者相应的功能性文件包实现快速开发。作为一线的程序员只需要去关注具体的业务逻辑，不需要去关注具体的技术细节。
在海量技术文档的帮助下，即使是新来的员工，也能快速完成开发。运营通过可视化的开发平台，可以实现组件的拼装，从而完成功能开发，通过一键发版，进行测试和上线，程序员在这里起到辅助的作用。这个时候的基础架构应该已经有很多的积累，大多数项目都可以实现拿来即用的程度。箱子里的工具多了，做什么都比较顺手。前端从造工具进入用工具的阶段。
智能时代
这个时期的前端团队规模应该在 50 人以上，具体数字全靠自己估计，不要深究合理性。公司业务会以千亿规模计算，公司人说会在 1000-100000 之间。涉及的应用可能没有一个人真正的去统计过，因为实在太多了。
这个阶段的一些 leader 或者资深技术可能需要进入深度的商业发现或者商业决策。基础设置除了上面的拿来即用，更多的是实现智能化，设计的东西能通过智能化迅速转化为代码。运营不需要再盯着前端写代码，因为他们通过可视化界面已经可以自己完成功能的开发和上线。
这个阶段的团队不仅有大量的工具，还有大量的物料，通过智能化的方法实现无感开发。这些技术实现不仅影响到公司的技术发展，而且影响到整个行业的生态。我们期待这个时代的到来。
四、如何建设基建团队
有的公司有专门做基建的团队，比如架构组，运维组之类的部门；有些公司的程序员是一边做基建一边开发业务代码。这是两种不同的组织形式，没有好坏之分，只有是否适合的区别，当然其中也会涉及到一些行政干预的力量。
不同的公司可以根据不同的情况进行设计。以上两种组织形式，归根到底都是为了解决一个问题：怎样找到合适的人去做合适的事？
需要做什么样的事
需要什么样的人
什么性格的人
技术上的支持
以上根据基建的点选择不同技术栈的同学来做。
五、基建工作如何落地
基建工作的落地实施除了需要技术的热情，同样离不开公司 CTO 甚至是大 Boss 的支持，要多学会用数据说话，通过数据和收益来证明一件事情的必要性和可行性。这是前提，缺乏这个前提你做的事情可能并不会得到各方面的支持。
同时，基建工作的落地和选的人有密不可分的关系。如果在一开始做的时候就没选好人，那么基建的效果可能会大打折扣，甚至做出来的东西根本没人用，以至于后期没人维护没人管。
另外要做好数据统计工作，做出的东西在交付使用之前尽量做好使用量统计工作。比如，可以统计一个组件库在整个前端团队的引用次数有多少，一个工具的打开率有多高，节省了多少的人力成本，节省了多少的时间。
这些东西如果能有可视化的界面做支撑，下次再做基建立项的时候，被领导信任的概率就会大大增加。