- 综合排序
- 最热优先
- 最新优先
- 来自专栏CODING DevOps
大型前端项目 DevOps 沉思录 —— CI 篇
本文作者：成龙 腾讯前端开发工程师，负责腾讯文档前端开发与研发效能提升，AlloyTeam成员。 编译并整理产物 在中小型项目中，这一步通常会被直接省略，直接将构建产物交由部署环节实现。但对于大型项目来说，多次频繁的提交构建会产生数量庞大的构建产物，需要得到妥善的管理。 这对于发布频率越来越高，发布周期越来越短的现代大型项目中无疑是一个最优解。 3. 大型项目中产物->制品的建立 对于大多数项目来说，在代码编译完成生成产物后，部署项目的方式就是登录发布服务器，将每一次生成的产物粘贴进发布服务器中。 这是每一个成功的大型项目最终一定要实现的目标。 参考资料 1.
58630编辑于 2021-12-03 - 来自专栏腾讯云原生团队
大型前端项目 DevOps 沉思录 —— CI 篇
成龙，腾讯前端开发工程师，负责腾讯文档前端开发与研发效能提升，AlloyTeam成员。 编译并整理产物 在中小型项目中，这一步通常会被直接省略，直接将构建产物交由部署环节实现。但对于大型项目来说，多次频繁的提交构建会产生数量庞大的构建产物，需要得到妥善的管理。 这对于发布频率越来越高，发布周期越来越短的现代大型项目中无疑是一个最优解。 大型项目中产物->制品的建立 对于大多数项目来说，在代码编译完成生成产物后，部署项目的方式就是登录发布服务器，将每一次生成的产物粘贴进发布服务器中。 大型项目中，随着各项指标计算的接入，各项测试用例的数量逐渐增多，运行时间迟早会达到我们难以忍受的地步。 但是，测试用例的数量一定程度上决定着我们项目的质量，质量检查决不能少。
59130编辑于 2021-12-03 - 来自专栏趣学前端
「前端经验总结」大型业务项目中，前端如何撰写设计文档
项目开发流程 看一下这个项目开发流程图，当项目启动之后，产品的同事会先来一轮需求宣讲，告知大家本期大致做什么，产品的同事会整合各方的发言在完善一轮功能。 下面我以最新一期接第三方支付的需求为例，讲讲这个耗时半个月的项目是怎么写前端设计文档的。 批量是为了解决超过100条数据操作的问题，所以批量导入的数据是不设限制的，这个时候后端可能一次性给过来几千条数据，前端一次性加载有一定概率导致页面卡顿。 1、数据量过大解决方案 参考了林三心大佬的「后端一次给你10万条数据，如何优雅展示，到底考察我什么?」 方案名称 优点 缺点 通过账号信息 1、如果接口返回了明显的标识可以区分当前用户的类型以及支付类型，可以直接使用； 2、如果没有，则前端按照用户的类型，手动添加支付类型标识。
1.1K30编辑于 2023-03-31 - 来自专栏程序员成长指北
基于微前端的大型中台项目融合方案
这篇文章通过实现一个商城后台，介绍了基于 umi 框架的微前端落地方案，通过这篇文章，你可以收获 超级简单的、可用于生产环境的基于 umi 的微前端实践，包括一套示例代码 全新的、基于微前端的大型中台项目前端组织方式 比如我们要做一个大型的商城后台，商铺管理和用户管理分别由两个团队开发维护，那我们可以将前端应用拆为主应用（layout）、商铺管理应用（shop）、用户管理应用（user），然后通过微前端组织起来，最终效果如下图 ，可以完美的拆分大型中台项目，也可以平滑的升级历史应用。 总结 微前端为大型中台项目带来了福音，我们可以非常灵活的进行应用拆分和组合。基于这一套玩法，我们不仅可以完成“总分”形式的组合，也可以实现“任意套娃”，极大的提升了中台应用的灵活性。 我想象中未来的中台前端也是微服务化，每个小组维护自己的数据和页面，通过“总分”和“套娃”组成一个大型中台应用。
1.7K10发布于 2020-09-08 - 来自专栏用户6296428的专栏
适用于既有大型MPA项目的“微前端”方案
作者：杨超 团队：业务中台 一、背景 对于大多数有点历史的复杂前端项目来说，应该已经经历了从刀耕火种的大型单仓库构建到多业务应用独立开发部署的过程。 毕竟， MPA架构的前端不是 生而为快，其最大的优势在于开发和维护的高效。 那么，在面对一个大型的 MPA架构前，我们的页面还可以再快一点吗？ 这时候天空飘来了两个字—— MicroFrontend，微前端。微前端的定义想必大家都看了很多，大多数是起源自于 micro-frontends.org 和各个大牛自己的独到见解。 本文所介绍的方案并非全套的微前端方案，不包含独立发布、部署、依赖拆分这一部分的内容。 在分析了这些微前端方案的实现，并结合团队内的现状后，我们实现了自己的渐进式微前端方案——ZanSpa（命名就是这么简单朴素）。主要设计思路如下图所示： ?
2.1K20发布于 2020-08-24 - 来自专栏腾讯技术工程官方号的专栏
大型前端项目的断点调试共享化和复用化实践
作者：enoyao，腾讯工程师 背景 随着我们项目越来越大，我们有可能需要维护很多的模块，我们腾讯文档 Excel 项目大模块有 10 几个，而每个大模块分别有 N 个小模块，每个大模块下的小模块都有主要的负责人在跟进模块问题 ，让他去慢慢定位问题，这样的每个新同学对模块的熟悉，学习和维护的成本就会变得越来越大，项目越大这种情况就会越严重！ 方案 由于上面的问题真的很痛，我们在爬滚中逐渐摸索了一套方案，我们暂且叫它为基于断点调试的共享化和复用化的实践方案吧，这里有个关键词是断点，相比作为每一个开发者都不陌生，在我们前端，模块定位问题的时候， debugger 位置 pasteFromInter 2 行 4 列 isShapePasteFromOuter 256 行 89 列 isImgPasteFromOuter 867 行 12 列 对于大型项目来说 当然实际情况可能还要比想象中复杂，举个简单的例子：因为分发的开关有可能会注入到一些被打包到 worker 的代码里面，worker 在大型项目中运用的很多，但是 worker 里面无法读取 document
1.1K107发布于 2020-10-10 大型前端项目性能瓶颈：内存泄漏排查与解决方案
大型前端项目性能瓶颈：内存泄漏排查与解决方案 背景与症状 长时间使用后页面越来越卡顿，滚动或交互明显变慢；内存占用持续上升且不回落 典型指标：用户设备内存占用（UA-specific memory）上涨 、FPS 降低、GC 频率升高、主线程占用增多 高风险场景：大型单页应用、长列表、复杂图表/Canvas、WebSocket/SSE、频繁路由切换、跨标签页缓存 常见泄漏模式 未清理的事件/定时器/观察者 ：组件销毁后闭包仍持有大对象或 DOM 引用 WebSocket/SSE/Worker：连接与线程未按生命周期关闭 图像与 Canvas：未释放引用、离屏 Canvas 未清理、超大位图持有 路由与微前端 周期性采集 UA-specific memory 与页面交互事件；异常升高告警 错误平台：记录 OOM、AbortError、TimeoutError 等与内存快照元数据（路由、设备） 指标面板： 前端 Puppeteer 内存趋势脚本 文档：是否记录组件与资源生命周期 知识库：是否沉淀常见泄漏模式与修复方法 结果与总结 通过快照对比与保留路径定位，结合资源生命周期清理与缓存策略，可系统性消除内存泄漏 在大型前端项目中建立
58210编辑于 2025-12-15大型前端项目代码拆分：按业务模块 功能维度的实战思路
大型前端项目代码拆分：按业务模块 / 功能维度的实战思路 目标：提供一套在大型前端项目中实施代码拆分的可执行方法，覆盖按业务模块与按功能维度的两种视角，并给出目录规范、构建配置、状态与依赖治理、迁移步骤与实战案例 Monorepo（推荐大型项目） repo/ apps/ web/ # 主 Web 应用（聚合业务模块） admin/ 模块间通信优先事件总线（pub/sub），定义事件命名与载荷结构 状态边界：全局只保留会话级核心（登录、权限、主题）；业务状态留在模块内，通过共享服务或事件同步 构建与加载策略 路由级拆分与多入口 多入口：大型模块或应用独立入口 chunks: 'all', cacheGroups: { vendor: { test: /node_modules/, name: 'vendor', priority: -10 }, shared_ui: { test: /packages\/shared\/ui/, name: 'shared-ui', priority: 10 }, orders:
25810编辑于 2025-12-15- 来自专栏前端实验室
10个前端低代码开源项目
低代码实现大幅度的提效降本，为专业开发者提供了一种全新的高生产力开发范式，今天就推荐10个低代码平台，建议收藏！ Appsmith Appsmith 是一个用于构建、部署和维护内部应用程序的开源平台。 配置就能生成各种后台页面，内置 100+ 种 UI 组件，能够满足各种页面组件展现的需求，极大减少开发成本，甚至可以不需要了解前端。 Github地址：https://github.com/baidu/amis Github Star：14.1K tmagic-editor tmagic-editor是腾讯技术中心从魔方平台演化而来的开源项目 ，和大多数的前端低代码框架一样，采用的是编辑器生成页面JSON数据，服务端负责存取JSON数据，渲染时从服务端取数据JSON交给前端模板处理。 最新版本使用 uni-app 重构物料、模板项目，支持生成 H5、小程序多端商城。
3.6K40编辑于 2023-08-10 - 来自专栏程序员的知识天地
如何阅读大型前端开源项目的源码，授人以鱼不如授人以渔
这篇文章主要讲的是阅读大型的前端开源项目比如 React、Vue、Webpack、Babel 的源码时的一些技巧。目的是让大家在遇到需要阅读源码才能解决的问题时，可以更快的定位到自己想看的代码。 授人以鱼不如授人以渔，希望大家可以通过这篇博客，了解到阅读大型前端项目源码时的切入点。在之后遇到好奇的问题时，可以自己去探索。 这里要强调一下，大型的开源项目一般都会有一个 Contribution Guide，目的是让想贡献代码的开发者更快上手。里面就有讲怎么在本地构建代码。 我们鼓励大家在本地把大型项目的源码跑起来，自己随意把玩，研究。因为源码也是普通的代码，并没有太多门槛。 自己整理了一份2018最全面前端学习资料，从最基础的HTML+CSS+JS【炫酷特效，游戏，插件封装，设计模式】到移动端HTML5的项目实战的学习资料都有整理，送给每一位前端小伙伴，有想学习web前端的
1.5K10发布于 2018-10-27 - 来自专栏君赏技术博客
建议大型项目用上Try Catch建议大型项目用上Try Catch
建议大型项目用上Try Catch 我们在平时项目做功能的时候，经常会遇到崩溃的情况。如果是我们在开发测试阶段，我们可以找到原因修复。但是遇到已经上线，出现这种问题。 最近写的项目用Swift语法进行编写的，对于之前我们在Object-C中NSError**类型的指针标识遇到了什么错误，现在转成Swift方法直接进行throws进行抛异常。 比如我刚刚写的项目，就用上了，感觉用完顿时高大上了许多。
1.2K10发布于 2018-08-31 - 来自专栏全栈修炼
前端趋势榜：上周最热门的 10 大前端开源项目 - 210327
81 个视频讲解，每个视频大概 5 - 10分钟左右，还能学习英语哦 youtube 的教学视频：https://www.youtube.com/playlist? list=PLLXdhg_r2hKA7DPDsunoDZ-Z769jWn4R8 猫哥之前学习算法的时候，也在这个项目中收益良多呢！ 而且这个项目还一直有维护和更新内容哦！真的非常不错的一个项目！ https://github.com/trekhleb/javascript-algorithms 更多算法相关的项目推荐可以看看这篇文章：7 个 GitHub 上超火的前端学习的数据结构与算法项目 也是当今天前端最流行的编辑器！ https://github.com/tinacms/tinacms 10. tailwindcss +45 Star / day 一个实用程序优先的 CSS 框架，用于快速构建自定义用户界面。
2K20编辑于 2023-03-15 - 来自专栏深度学习与python
前端老手 10 年心得，JavaScriptTypeScript 项目保养实用指南
本文将基于我 10 多年来编写 JavaScript 代码的经验和 5 年多拯救 JS/TS 项目的经历，向读者介绍如下内容： 如何评估 JS/TS 代码库的质量和风险。 确保产品和技术代表能够公开、友好地协商功能性和技术性项目的优先级和规划。 关于如何在 TypeScript 和 JavaScript 项目中应用这些推荐做法的更多实用建议，我建议你参考 Yoni Goldberg 的最佳实践列表。 它们是为 Node.js（后端）项目编写的，但其中很多也适用于前端代码库。 前端框架 Svelte 作者宣布重构代码，反向迁移到 JavaScript 引争议](https://www.infoq.cn/article/dDXbcLHT7teNYSPL3sm7) Typescript
69510编辑于 2023-12-21 - 来自专栏愿天堂没有BUG（公众号同名）
SpringCloud实战：项目准备，构建大型实战项目
项目准备阶段 本章中，我们将开始一个大型实战项目——博客网站。通过“以战代练”的方式来学习如何构建Spring Cloud微服务架构，让读者走出理论的丛林，在实践中玩转微服务架构。 我们知道，在正式开始搭建框架之前，首先应分析项目需求，再进行原型和UI设计，接着设计数据库结构，最后根据项目特点进行技术选型。本章将依次为大家介绍框架搭建前的准备事宜。 一个好的项目开发，产品设计阶段需要占到整个项目进度的50%甚至更多，才能保证整个项目开发的合理性。 一个优秀的产品应遵循以下几个原则。 用户至上。 小结 通过本章的学习，我们了解到一个项目从需求分析、产品设计到最后的架构设计的整套流程。在实际的项目中,无论流程如何改变，这些基本思路是不变的。 本文给大家讲解的内容是springcloud实战：项目准备，构建大型实战项目博客网站 下篇文章给大家讲解的是springcloud实战：从公共模块入手搭建一套完整的微服务架构； 觉得文章不错的朋友可以转发此文关注小编
1K30编辑于 2022-10-28 - 来自专栏程序员成长指北
前端 “接活” 必备的 10 个开源后台管项目！
我在 Github 上收集了一些优秀的后台控制面板，并总结得出 Top 10。 、ant-design-pro Github Star 数 22600，Github 地址： https://github.com/ant-design/ant-design-pro 开箱即用的中台前端 10、material-dashboard Github Star 数 8600，Github 地址： https://github.com/creativetimofficial/material-dashboard
67240发布于 2021-09-22 - 来自专栏小白维基
「翻译」如何组织大型 Python 项目
分层架构确实能够有效降低大型项目的复杂度,方便独立开发。但也存在一些缺点,比如容易在高层产生过多代码,完全实施分层需要花费时间等。 总体来说,尽早引入分层架构,能够减少后期的重构工作量,是管理大型 Python 项目的一个有效方式。 本文通过一个真实的大规模 Python 项目案例,生动地介绍了分层架构的实施过程、优势和不足,对于管理大型项目很有借鉴作用。 看到上面的描述，你大概率会下意识地认为这个项目的代码肯定无比的混乱。坦白讲，我也会这么想。但事实是，至少在我工作的领域，大量的开发人员可以在一个大型的 Python 项目上高效地工作。 如果你正在开发一个大型的 Python 项目，或者哪怕是一个相对较小的项目，不发试试分层结构，还是那句话：越早分层需要面对的麻烦就越少。
97430编辑于 2023-08-09 - 来自专栏玩转JavaEE
大型项目的 Gitflow 实践
一、项目背景 我们的产品作为公司最重量级的产品，尝试使用git时（2016年10月）研发团队总体107人左右，研发经理6人、需求12人、架构师1人、系统分析师1人、测试26人、开发61人，整个团队负责全国 工具层面，主要是打分支、切换分支、合并等操作方便，打一个分支瞬间，切换分支10分钟左右（想想原来打分支搭建环境要1-2天）。 首先，gitflow仅仅是一个工具，能够有效提高发布频率，让大型项目更加灵活，带来的不便就是有一定的学习成本，管理成本有所提高（需要配套的工具才能降低），提高效率方面需要结合很多其他方面才能提高。 现实情况远比上面例子复杂，往往版本开始会根据团队规模规划需求，比如规划要做100个需求（实际客户反馈了200个），研发过程中会临时插入了50个，这150个当中可能有10个分析后可能不做了，可能有10个需求改动太大推迟到下个版本 现实情况远比上面例子复杂，往往版本开始会根据团队规模规划需求，比如规划要做100个需求（实际客户反馈了200个），研发过程中会临时插入了50个，这150个当中可能有10个分析后可能不做了，可能有10个需求改动太大推迟到下个版本
61140编辑于 2022-03-04 - 来自专栏python编程军火库
python 大型项目神器实战
/ python 生产实战 python 大型项目神器实战 / 在 fastapi 当一个新的请求到来的时候，实际的调用流程如下: 1.调用依赖项函数(传递合适的参数) 2.得到依赖项目函数的返回结果 3.把返回结果传递给路由函数中对应的参数 4.路由函数中业务流数据处理 5.获取的数据返回给客户端 /前端 2.1 函数级依赖项 # -*- encoding: utf-8 -*- from fastapi import Depends, FastAPI app = FastAPI() async
1.1K40发布于 2021-05-11 - 来自专栏DevOps时代的专栏
大型项目的 Gitflow 实践
一、项目背景 我们的产品作为公司最重量级的产品，尝试使用git时（2016年10月）研发团队总体107人左右，研发经理6人、需求12人、架构师1人、系统分析师1人、测试26人、开发61人，整个团队负责全国 工具层面，主要是打分支、切换分支、合并等操作方便，打一个分支瞬间，切换分支10分钟左右（想想原来打分支搭建环境要1-2天）。 首先，gitflow仅仅是一个工具，能够有效提高发布频率，让大型项目更加灵活，带来的不便就是有一定的学习成本，管理成本有所提高（需要配套的工具才能降低），提高效率方面需要结合很多其他方面才能提高。 现实情况远比上面例子复杂，往往版本开始会根据团队规模规划需求，比如规划要做100个需求（实际客户反馈了200个），研发过程中会临时插入了50个，这150个当中可能有10个分析后可能不做了，可能有10个需求改动太大推迟到下个版本 现实情况远比上面例子复杂，往往版本开始会根据团队规模规划需求，比如规划要做100个需求（实际客户反馈了200个），研发过程中会临时插入了50个，这150个当中可能有10个分析后可能不做了，可能有10个需求改动太大推迟到下个版本
1.1K50发布于 2019-10-21 - 来自专栏PM吃瓜(公众号)
大型项目中的敏捷项目管理实践
大家现在知道了，又遇到有中国特色的项目了，"需求范围不确定，资源限死、时间限死"，大家会说不是战略项目吗，资源怎么会限死呢？ 考虑该如何实施这个项目时，似乎传统的项目管理从计划来分配资源模式以及采用瀑布型的开发方式，根本行不通。 单元测试的实践，由于时间紧研发人员都担心会影响项目进度，因为本身测试代码工作量也不少。 由于团队之间对立情况，反而加剧了对文档传递的依赖，项目进度慢了下来。 结束语 敏捷开发的实践，一直都聚焦在单一团队运作，但当往往很多系统规模，并非 10 个人团队可以在 要求时间内交付的。
1K20发布于 2019-08-12
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号