引言
在这片有着基建基因的土壤上聊这个简直令人胆颤心惊，但安全。
本文老少皆宜，本着爱与和平的宗旨，不传达任何焦虑，主要分享自身搞基建的一些案例和体会，希望能给打算做基建或正在基建建设中的伙伴们一些参考，若能帮助到你们，我也会祝你们好运！
基建是什么
内容
基建是什么，字面意思：基础设施建设。嗯？好像等于没说。可能很抽象，在我们的研发世界里可以是通用技术的建设，或者再具体一点，比如一个方法被调用两次，你抽离出这个方法，沉淀下来，那这个方法就可以是通用技术。以此切入，放到场景中就衍生出了很多具体基建，本人是个前端研发，像我们就会做很多类如：前端工程化 / 数据可视化 / 多端生态 / 组件库 / 自动化构建部署 / 性能分析 / 埋点系统 /...
上面好似很牛的样子，可基建本不是什么高大上的词儿，只是一句话很长，概括一下就变成两个字儿了。
哇🤩 基建好简单诶！
有你受的。
特性
- 比业务研发更紧贴业务我们知道一般业务研发都能知道自己维护的这条线的业务模式，但公司其他业务线未必知道，而往往你的基建建设可能要支撑多条业务线，这就使得你要紧随着公司发展的脚步，不然面试官问你 xx 业务线做什么，你就只能说：这个业务我们基建不管的。
- 诉求方比产品更难缠一般简单的模式就是产品和研发分别生产需求和消费需求，这两个角色平时可能看似沟通顺畅、和谐相处，但也会因牛头不对马嘴而草草了事。
产品：你知道做什么吗？研发：emm 我明白。我通过 xx 技术、xx 手段，最后出来的会是这样的产品：嗯嗯好的 你能做好就行
毕竟专业上还是有区别，交流上难免有误解和盲区。
但基建对应的诉求方很多也都是研发，你会发现，你说的她真的听得懂，一个问题能问出八个问题来。
- 职能边界更泛往往做基建，还承担着技术支撑的职责，如果出现了问题不知道找哪个业务团队，那就找基建团队。经常听到一句话：不是他们的，那就是你的。哦！我真的会谢
你准备好做基建了吗
下面会分享一些案例和体会，大家酌情参考。
你做得好以终为始吗？
以终为始，道理咱都懂，说起来简单，嗯，说起来简单。
做基建一般研发周期长，不像做一个业务功能，周期可能在几天、几周，他可能要做几个月，规划甚至要规划到半年、一年的周期，我们常说研发要走在业务前面，不能业务来了，发现实现不了，而做基建要走在研发前面，比如为可预见的场景提前做好可行性探索和支撑，就是这个道理。
另一方面，很容易被业务牵着走，捡了芝麻丢了西瓜。之前我们做一个面向公司全量前端应用密集部署的系统，前期先支持 PC 应用，大部分应用都顺利支持了，但有个别特例应用比较难啃，当时我们为了支持这几个特例，调整了部分实现。正当我们觉得有阶段性成果了，可现实很骨感，下一阶段支持移动端应用发现不对劲，移动端流量比 PC 端流量多两个数量级，这需要很高效的扩缩容能力。而当时的调整对扩缩容方面有很大的阻碍，这一度使得我们没法推向移动端应用，而密集部署主要的核心也是针对移动端应用，毕竟移动端资源占比多得多。
点到为止，本想做个飞机，结果做成了拖拉机，倒也能带人。痛！真的太痛了！
你格局够大吗？
最近在做无相，一个表单搭建平台，面向公司几乎所有的业务线，这要求我们维护者要对所有业务线负责，而不能局限于某个业务线，如果只看到局部，很容易就造成在胡同里走死的情况。所以格局打开，不要在细节上死抠，而忘了全局的模样。目前每个月都有各种业务方的诉求得到支持，这时常提醒我们要保持好格局，不拘小节，毕竟哪个业务方爸爸都得罪不起，更不用说一堆业务方了。
你有全栈意识吗？
你们有过这样的经历吗？打开 Axure 设计流程，需要个图片，然后打开 PS 制作图片，再用 VSCode 进行编码，偶尔还得充当客服答疑解惑。基建一般是个偏技术类产品，但未必会像业务产品一样有足够的产品、设计等资源。是的，这就是基建的家庭地位，啥条件啊，搞个基建这也要那也要，那怎么办，想要出成果那就自己搞咯。所以你要有全栈意识，做好啥都要干的准备。
对了，我司的基建是有对应的产品和交互的。
你能两只脚走路吗？
很多基建是以平台的方式呈现的，比如前端构建平台、运维保障平台等等。一般这类平台都会涉及到两方面：底层架构（平台能力的实现）、平台产品（暴露给用户侧的平台功能）。这两方面一定要同时进行，否则会给你带来很多意想不到的问题。之前做的一个项目，精力都侧重在了底层架构，能力具备齐全，但产品功能很简单，只是最核心的功能。结果平台一推出后，直接把客服系统整崩了，当然客服就是我自己，想看个数据页面看不到，我得调用接口帮他们查；流程报错终止了，怎么重新开发，也得手动调用接口触发等等。
这两方面相辅相成，不能埋头专搞底层，也要不断的迭代产品功能，接受用户的反馈，再反馈推动底层的设计。
你能渐进式推进吗？
渐进式开发大家应该都知道，渐进式推进也同样的道理，不要想着所有业务方能很顺利的接受一个新事物，除非你真的为所有业务方都带来了很大收益。现实更多的是先推少部分业务方、先小幅度升级，循序渐进的推进，再收集反馈来优化下次的推进，这样可以形成正向循环。
另外，基建是需要持续验证的，每个阶段要有里程碑来验证可行性，不可能等你开发两个月，出来个东西发现跑不了，那么你也跑不了了。
你对边界够敏感吗？
有一个明显的感受是做基建后平时一起协作的伙伴变多了，那是因为基建可能依赖于多方资源，因而对应的边界也会多很多，比如以下一个搭建的架构图，大的分层这么多层，更不用说再细分的了。
图片
可想而知，实现一个功能可能就需要多方协助，哪一层应该做什么，是否严格按照分工来，就变得格外重要。前不久做一个表单性能优化的事儿，一开始围绕着渲染层进行方案设计，浅浅评估了一俩个月工作量。后面在全局架构下 review 后，发现一部分内容应该交由物料库去做，结果一评估，渲染层和物料层各一周就可以搞定。
你的基建真的好用吗？
是骡子是马拉出来遛遛。架构很牛？平台很好用？自我感觉良好没用，还得主动拿出来让大家检验。比如分享你的平台给业务团队，听听他们的声音，他们说好自然最好，说你哪方面不行，也得认，这对你其实很重要。我很喜欢老罗，尤其是他在新品发布会上演示出现 bug 的时候，真是又惊又喜，但他从不否认问题，骂手下就行了。
定期开展架构 review，这个很有必要，看看基于以前背景下的设计是否在当下的背景依然跑的很溜，不然发现设计不适用了也是很正常的，只是要持续调整罢了。
对，只是要持续调整罢了。
你有数据吗？
对于公司而言，肯定是要计算每个团队的成本和营收的，而基建团队的营收不像业务团队有业务数据可以比较直接的推算出来，它可能需要间接计算。比如你说降本提效，到底给多少业务团队提效了，提效了多少人力都要统计出来，这就是最直接的价值体现。基建做的多牛，你没数据，可能就等于白做。
另外，通过分析业务的数据，除了能证明自身的价值外，还可以帮助业务去纠正一些问题，比如观测业务的一些使用状态，产出业务维度的晴雨表。
比起口碑，老板可能更相信数据。
你确定能 hold 住问题吗？
问题当然是解决不完了，但是问题解决不了那就是另一回事了。这取决于你方向的把控，前进步伐的控制，向来这种情况是求稳不求快，要控制在自己团队能 cover 范畴内。比如你前期的技术栈选择要基于团队的技术栈，不可盲目求新，不然到时候可能一发不可收拾，问题来了四处求人，依赖的外部资源有问题，可能还得依赖于外部的进度。
当然，也许你技术很牛，这方面做的不错，但不得不提的是还有一方面问题是答疑问题，可想而知，这方面问题会随着业务的深入接入越来越多，这就需要你有更强的软性技能。另外也要有意识通过各类工具来优化答疑链路，减轻响应成本。
你有足够技术热情吗？
因为业务项目要更稳定，所以一般技术选型会更可控，并且技术层面的调整不应该很频繁。而基建会相较更自由一点，且要走在业务开发前面，需要调研很多技术，对比多种技术方案，为下一个瓶颈期提前做准备，这也是为后续业务破局奠定技术基础。
不过，探索新技术可不是喜新厌旧，可不是旧的要废弃，要而是要了解各种技术的优劣，便于落在场景中选择最合适的方案。
总结
基建不是为了做而做，他也是要能解决真实问题的，脱离业务的基建都是耍流氓。从未觉得做基建比做业务的🐂，基建的家庭地位都是垫底的。
如果你没做基建，请友善对待你身边的基建伙伴吧！
如果你要准备做基建，就冲吧，你注定有这一劫！
如果你正在做基建，那一起共勉！
如果说了这么多，你们还没有醒悟的话，不妨来我司看看，有很多基建已经活了好几年了，现在依然还坚强着。
- 鲁班系统：一个基于业务组件快速生成页面的搭建系统。
- 门神系统：一个主要用于对接公司内部系统，为内部系统建立起一套完善的权限管理机制。
- 云长系统：一套云端构建工具，提供了前端项目构建、合规检测、发布等功能，并统一了工程协作流程，使得前端同学在应用开发过程中得心应手。
- 百策系统：一个可以对页面进行性能检测并提供优化指引的系统，可以展示一段时间的性能走势，提供检测接口服务。
- 浑仪系统：用户行为采集及分析，助力用户建立高效的数据指标体系
- 无相表单系统：一个可以快速生成表单的搭建系统。
- 插件体系：主要解决开发中的场景里面涉及到的各种问题的辅助帮助。
