我在2年之前，写过一篇中小型项目的前端架构浅谈。随着能力的上升，以及在阿里巴巴工作的经验，是时候写一篇大型项目的前端架构分析了。 本篇文章不会更多侧重于具体技术实现，而是尝试从更高角度出发，分析为什么要这么做，这些设计能解决什么问题，成本和收益如何。 由于作者能力有限，可能会有…

OpenDoc我们将团队内部的部分文档经过编辑共享出来，主要出于以下考虑：我们希望有志于加入团队的朋友能得到同等的信息，做好相应的准备；团队的工作经验与方法的分享和技术分享一样是有价值的；听取同行们的改进建议 主要原则CodeReview与代码流动绑定，有合并必有ReviewC…

团队开发中，多人开发同一个项目，由于个人编码习惯不同，一个项目中最终的代码风格可能差别很大，所以需要通过工具进行约束来保证代码风格的统一。同时也希望通过工具尽可能的减少低级错误出现，并且能帮助修正，所以有了各种各样的 lint 和 formatter。 本篇的目标是使用 vsc…

一直是ESLint的忠实用户，深知规范的重要性。然而，在新项目交接中，我被GitCommit规范逼疯了。才意识到自己的疏忽，于是便有了一探究竟的想法。一、为什么需要规范？无规矩不成方圆，编程也一样。如

以下代码风格仅供参考，没有明确规定那种书写方式好，那种书写方式一定就不好，代码风格的统一，目的就是提高代码的可读性。 建议使用行注释 (在Sass中是//) 代替块注释。 建议注释独占一行。避免行末注释。 使用.scss的语法，不使用.sass原本的语法。 当一行长度达到了单行…

不以规矩，不能成方圆。 对于团队而言，统一很重要，代码是写给人看的，然后顺便跑在机器上而已。 每一种事物都有它被发明时，都会有其用处和目的，每一个事物都是自己擅长和适合的领域； 我们要在对的地方使用它，让它做自己擅长的事。 我们知道，当一个团队开始指定并实行编码规范的话，错误就…

好的注释可以提高代码的可读性和可维护性，从而提高代码质量。 那么什么是好的注释？如何写出好的注释？本文将从注释的目的和原则出发对 JS 注释进行探讨。 我们写注释，是为了给代码的读者（包括我们自己，也可能包括机器，如 jsdoc）看，帮助读者阅读理解代码并进行维护。 「如无必要…

1. 编码规范 相信编码规范对于大家来说不算是陌生，如果在 9102 年再次聊起这个话题，恐怕耳朵会起茧，但编码规范从制定到落地是一个艰难的旅程，特别是对于不同成员的编码习惯，还有棘手的祖传代码。无论你是老司机还是新手不妨了解一下。 如何制定编码规范？这是一个永恒的话题，甚至出…

前端团队有评审代码的要求，但由于每个开发人员的水平不同，技术关注点不同，所以对代码评审的关注点不同，为了保证代码质量，团队代码风格统一，特此拟定一份《前端团队代码评审 CheckList 清单》，这样代码评审人员在评审代码时，可以参照这份清单，对代码进行评审。从而辅助整个团队提…