文章小结这个是在qq音乐商业化团队在2021年3月份的总结文章。行文的内容有五个点：1、模块化（包含js模块化、CSS模块化），2、组件化3、规范化（包含代码规范、文档规范、流程规范）4、自动化：（包含构建编译、测试、CI/CD等）5、业务分析与改进。文章开头对简单工程化的生命周期划分我还是比较认同的，它包含了：项目的架构设计的初始化 -> 项目开发 --> 测试部署 --> 构建与部署 --> 运维管理。但实际文章中的内容来说的话，就是写的很细节，然后标题写的很大但是文中的内容就显得比较空。感悟我由于以前之前我在应用宝、微视、腾讯云都工作过，对腾讯内部MIG\PCG\CSIG各自体系的工具和系统都比较熟悉，然后作为面试官、参加各种行业内的大会，也了解了国内其他企业或公司内的系统大概情况。其实整个工程化来说是一个很大的课题，要想把整个项目或者是整个业务完全工程化的话，一个是费很大精力，二是要有一个全局的视角和思想来统领整个研发的投入。不过要对某一块业务或者是某一个系统做那个前端工程化的话，我可以给一些建议。【留个坑后面慢慢来补文章】这里先用 《前端工程化：体系
Chroma 是一个用于构建带有嵌入的 AI 应用程序的数据库。它内置了您入门所需的一切，并可在您的机器上运行，支持python 和 javascript版本。Chroma 为您提供以下工具：存储嵌入及其元数据嵌入文档和查询搜索嵌入色度优先：简单性和开发人员生产力搜索之上的分析它也恰好非常快Chroma 由Python客户端 SDK、JavaScript/TypeScript客户端 SDK 和服务器应用程序组成。查看Colab 演示。项目地址官方文档：https://docs.trychroma.com/github地址：https://github.com/chroma-core/chroma
概要说明格式说明有两类主要的音频文件格式：无损格式，例如WAV，FLAC，APE，ALAC，WavPack(WV)有损格式，例如MP3，AAC，Ogg Vorbis，Opus.序号类型说明1cdaCD音频格式扩展名2wav微软公司开发，用于保存WINDOWS平台的音频信息资源。3mp3全称MPEG：MovingPictureExpertsGroupAudioLayer-3，是目前用户最多的有损压缩数字音频格式。4aif/aiff苹果计算机公司开发的一种音频文件格式。5mid经常玩音乐的人使用，最大用处是在电脑作曲领域。6wma即Windows Media Audio，来自于微软。7ra主要适用于在网络上的在线音乐欣赏。8vqf雅马哈公司的一种声音格式，可以用雅马哈的播放器播放。9ape目前流行的数字音乐无损压缩音频文件。项目应用说明在视频编辑剪辑项目中主要使用：Mp3,AAC,Ogg,Wav, FlAC, APE等，如果前端无法识别需要服务端转码处理好后给前端一个规范的编码类型。不同类型在采集频率、编码方式、压缩率等都不太一样,另外在音频处理过程中还有增强、降噪、AI语音识别，网络与传
共享文档来源 于2021年 tweb 大会宣传资料1、渲染管道优化以表格为例，对layout布局，paint 优化。尽量避免几何属性修改导致全局layout的修改.paint only 修改减少repaint.2、DOM 复用dom 复用减少渲染的dom节点数量3、升级 canvas 渲染解决复杂页面和页面滚动后，由于layout与 recalulate style 开销增长过大问题。4、解决canvas 的性能问题a) 减少渲染时触发GC。优化gc的逻辑b) Canvas API 调用的优化 strokeStyle、fillStylec) canvas 渲染复用，后面几页都是凑得内容[肖骏_腾讯文档渲染优化之路.pdf] https://docs.qq.com/pdf/DYk1QV1djbENGWnZw?
本文是读了腾讯文档前端TechLead, T12大佬曾探哥。 他经历了腾讯文档前端从0.1到现在的建设过程，和团队同学一起持续对腾讯文档前端进行架构优化，对前端架构设计有一些经验和兴趣 。 《JavaScript设计模式与开发实践》作者。这6-7万字文章中蕴含很多大型项目设计的经验和感悟，值得学习和借鉴。1、模块依赖优化a) 理清模块结构依赖，分类管理。当小团队3-5个人的时候项目架构依赖还很好管理，尤其到项目规模变大了，以及团队规模也变大了，整个架构、模块、类、函数、工具、相关的复杂的和层级变深了，整个项目的管理难度会指数级上升，到后续一定要分工明确，边界与规范也需要明确。尽量减少不必要的依赖。b) 合理抽象模块，降低耦合复杂度在开发的过程中，一定要随着系统的升级迭代、新人加入一定要做好培训讲明规则，保持好各个模块之间的功能单一性、独立性、复用性。 模块功能职责单一之后，对模块的迭代修改就会相对简单，不至于牵一发而动全身。针对业务逻辑一定要有核心人物多来思考抽象业务逻辑。让模块具有普适性。c) 代码架构分层，提升稳定性数据、逻辑、UI分层管理，梳理出核心业务层封装，对核心逻辑的质量提
开源常见的问题和解决流程方法当业务有国内、出海规范需求的时候一般会对开源组件有明确合规的要求,如文中所示:1、开源信息整理对项目中使用的每一个开源组件名称、版本号、下载链接地址，并确认是否对开源软件做出修改，是否对开源软件进行分发。一般情况需要尽量保证提供的信息准确，开源软件使用的许可协议可能因不同版本而存在类型差异，因此开发团队需要提供准确的版本号，准确的下载链接，明确开源软件许可协议文件，以免在审核过程中出现问题。2、怎样判断是否对开源软件构成分发？以任何方式对外（譬如用户）提供开源软件，例如通过邮件、U盘、云、私有部署等使外部能够获得开源软件，即构成分发。通过SaaS等仅提供服务，而不提供开源软件的，则不构成分发。以下表格列明的场景可供开发团队参考。开源组件（源代码/二进制代码）在哪里调用不构成分发构成分发仅在服务后端√ 从第三方软件库下载至客户端电脑/手机/其他终端设备√ 提供私有部署云端产品 (即是开源软件组件须要安装于客户的服务器里) √其他人在自己服务上下载至客户端电脑/手机/其他终端设备 √提供下载 √以任何其他方式提供给客户使用 √3、对外分发开源软件应注意什么对外分
最近在优化业务在国内外合规问题，并整理了所有依赖包的开源协议，顺便讲开源协议的规则共享一份。常见两类开源开源协议上百种。常见的开源许可协议主要有 Apache、MIT、BSD、GPL、LGPL、MPL等，可以大致分为两大类：宽松型开源许可协议和传染型开源许可协议。宽松型其中宽松型开源许可协议有Apache、MIT、BSD；协议说明1、BSD（二条款版）分发软件时，必须保留原始的许可证声明。2、BSD（三条款版）分发软件时，必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。3、MIT 分发软件时，必须保留原始的许可证声明，与 BSD（二条款版）基本一致。4、Apache 2 分发软件时，必须保留原始的许可证声明。凡是修改过的文件，必须向用户说明该文件修改过；没有修改过的文件，必须保持许可证不变。基本特点:1、没有使用限制。用户可以使用代码，做任何想做的事情。2、没有担保。不保证代码质量，用户自担风险。3、披露要求（notice requirement）用户必须披露原始作者。传染型传染型开源许可协议有GPL 、LGPL、MPL。协议说明1、Affero GPL (AGPL) 如果
小码哥
十年老程序员
粤ICP备2023052298号-1
