前端团队规范之路

首先声明一点：个人规范绝不是团队规范。 参考下旧的： 代码 为什么代码规范要统一？就一个字，爽，维护别人的代码就像改自己的一样！ 代码·真 规范是强制性的，会压抑大家的个性，不苟同。不过有些基本的可以拿出来说说，比如： tab 使用空格人性化的变量名注释项目 README.mdetc etc... Eslint 其实很舒服了，比背背佳还好；关于 CSS 推荐 stylelint 工具；HTML 按照 IDE 的智能提示也不会错，且尽量语义化。 三剑客 show code: /** * 随意命名不可取，人性化更利于维护 */ function a() { b.forEach((c, i) => { // 这里知道 a、b、c、i 变量是什么 // ... // ... // 100 行后： // 这里完全不知道干嘛了 }); } // good function renderCommoditys() { commoditys.forEach((commodity, index) => { // ... }); } /* 嵌套过深不可取，应不超过 3 级 */ .a { .b { .c { .d { .e { // 火箭式代码 } } } } } // good .container-commodity { .comodity { .comodity-content { } } } .commodity .commodity-detail { .commodity-name { .commodity-name-tag { } } } <!-- 纯 div 不可取，语义化不仅利于阅读，SEO 亦有好处 --> <div> <div> <div></div> </div> </div> <!-- good --> <section> <p> <span></span> </p> </section> js 中注释的一些写法。参考 https://jsdoc.app /** * JSDoc 注释 */ /** * 问候函数 * * + 作用 1 * + 作用 2，一些 `code` * * @param {String} name 姓名 * @returns {String} 问候语 */ function say(name) { return `Hello, ${name}!`; } /** * 状态 * * @var {Object} */ export const STATUS = { /** 在线 */ ONLINE: 1, /** 下线 */ OFFLINE: 2, }; 其它的就是些最佳实践了，比如：React/Vue 组件怎么写、面向对象编程。 Code Review 说的再多也是王婆卖瓜，一个人成不了团队，因此 CR 应运而生。 扯一些好处： 代码质量及时发现问题开发备份（同步项目给大家）师夷长技 进行 CR 的要点： 要快。别人也要时间开发的要多。三个臭皮匠，每个都能发现不一样的地方要早。尽量在 bug 改完后就进行，毕竟准备上线时代码不可能改动什么了 Github 上的 Code Review 协作 主要是和后端的协作，确保无后顾之忧。分为几个阶段： 系统设计。需要后端配合的 or 有更好的方案的接口字段定义接口评审。规范化的文档编排、确定联调时间【重要】代码里附上接口文档地址联调，接口改动督促后端更新文档【重要】发布上线，跟进 和其它部门的协作就是：多沟通，有问题及时抛出等等 知识储备 不仅对新项目接手、新人有益，更重要的是自己的沉淀与进步。 团队文档 项目 README.md，可以写一些项目启动、相关文档、注意事项、设计思路等等。项目更新文档，排期时编写，有相关的格式，就算有不同的也不会差太多。集锦。一些技术、文章分享，踩过的坑，笔记等等 个人学习 学无止境，自己学习的提高也是团队成长的体现。 不进则退，摩尔大爆炸的前端更如此。 掘金上的热文，如何在疲劳的JS世界中持续学习。还有些就是分享了 参考链接 非常全面的前端协作规范CodeReview规范写代码时，缩进使用 tab 还是空格前端的痛点之与后台和产品经理的协作