朝阳网站开发联系电话,网站备案信息核验单,做什么网站比较简单,微信运营软件简介#xff1a;  **越高级别的程序员往往越看重代码质量。** 本篇文章主要聊一下在团队开发过程中#xff0c;如何做到代码质量的管控与提升。首先需要有一套规范#xff0c;定义什么是好的代…简介  **越高级别的程序员往往越看重代码质量。** 本篇文章主要聊一下在团队开发过程中如何做到代码质量的管控与提升。首先需要有一套规范定义什么是好的代码再通过一些工具帮助我们在实践规范的过程中更好地遵循规范。 TLDR: 越高级别的程序员往往越看重代码质量。 本篇文章主要聊一下在团队开发过程中如何做到代码质量的管控与提升。首先需要有一套规范定义什么是好的代码再通过一些工具帮助我们在实践规范的过程中更好地遵循规范。 TLDR: 直接看第 4 点 Iceworks Doctor 解决方案。 为何需要提高代码质量 好的代码一定是整洁的并且能够帮助阅读的人快速理解和定位。好的代码可以加快应用的开发迭代速度不必花过多的时间来修复 bug 和完善代码。好的代码不但能够使得新的项目成员更容易加入项目同时方便项目组成员快速做好 Back up。好的代码便于促进团队间交流合作提升开发效率。 有编码经验的人对代码都有一定的“鉴赏力”能够凭感觉给出代码好坏的主观评价。但是这种凭感觉的方式太过个性随意所谓仁者见仁智者见智很难达成共识那有没有一种公认的标准来鉴定代码质量呢 代码质量评价标准 答案是有的。这里简单分享当下较常用的评价标准其中包括编码规范、可读性、可维护性、重复度及可测试性。 编码规范 主要包含是否遵守了最佳实践和团队编码规范是否包含可能出问题的代码以及可能存在安全的漏洞。编码规范有助于提高团队内协助的效率以及代码的可维护性。 可读性 Code Review 是一个很好的测验代码可读性的手段。如果你的同事可以轻松地读懂你写的代码那说明你的代码可读性很好反之则说明你的代码可读性有待提高了。遵守编码规范也能让我们写出可读性更好的代码。 可维护性 代码的可维护性是由很多因素协同作用的结果。代码的可读性好、简洁、可扩展性好就会使得代码易维护更细化地讲如果代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等等那就可能意味着代码易维护。除此之外代码的易维护性还跟项目代码量的多少、业务的复杂程度、利用到的技术的复杂程度、文档是否全面等诸多因素有关。 重复度 遵守 Don’t Repeat Yourself 原则尽量减少重复代码的编写复用已有的代码。对项目定期进行代码重复度检测是一个很有意义的事可以帮助开发人员发现冗余代码进行代码抽象和重构。重复的代码一旦出错意味着加倍的工作量和持续的不可控。如果代码中有大量的重复代码就要考虑将重复的代码提取出来封装成公共的方法或者组件。 可测试性 代码可测试性的好坏同样可以反应代码质量的好坏。代码的可测试性差比较难写单元测试那基本上就能说明代码设计得有问题。 除此之外还有很多代码质量评价标准。我们需要一些取舍选取部分大家有共识的规则定义团队好的代码标准。 代码质量建设怎么开始 当团队有了统一的代码质量评价标准后便需要严格的执行代码编写规范。 工欲善其事必先利其器 我们可以通过 SonarQube 等静态代码检测工具来进行代码质量建设。但在代码完成发布后如果线上没有问题的话相信很少有人会主动优化代码即使有扫描结果也很难推动代码质量的提升。 所以这里很需要平台、工具或者工作流上的配合。否则在具体写代码的过程中很容易由于开发人员的不重视导致整个 Code Base 变得越来越差。所以提高团队对代码规范的认同及严格执行是代码质量建设的关键。 当然我们也可以在代码提交的时候利用钩子来控制允许提交或者拒绝提交比如 git 的 pre-commit 和 commit-msg。但是这些都是比较滞后的方式我们能不能更提前发现问题让开发在功能开发过程中就把发现的问题改掉 Iceworks Doctor 为实现 JavaScript 代码规范的统一并提升和改善团队代码质量我们当前发布了 Iceworks Doctor 0.1.0 版本。该方案目前包括多场景统一的 ESLint 规则配置、多维度的代码衡量标准、执行分析扫描代码及代码修复等模块。通过各个模块协调配合评估质量评分并修复规范问题在降低维护成本、提升执行效率的同时保障代码规范的统一。 质量评分 当前版本通过 iceworks/doctor 从 5 个维度对代码进行评分 最佳实践 通过 iceworks/eslint-plugin-best-practices 分析项目提出符合当前工程特征对 ice 和 Rax项目友好的最佳实践及阻塞问题发布卡口帮助开发者优化项目性能避免潜在 bug 。安全实践 通过 iceworks/eslint-plugin-security-practices 扫码代码检测工程中可能存在的安全风险包含 url 、敏感成词、明文账密信息及 npm 包证书检测降低项目安全风险守卫项目安全。阿里代码规范 这一维度主要反馈开发人员对于 eslint-config-ali 阿里开发规约的遵守程度。可维护度 通过 typhonjs-escomplex 对文件进行扫码得出每个文件的可维护度可读性及复杂度评分。针对得分较差的文件可以进行深度分析帮助开发者更好的重构复杂代码。重复度 通过 jscpd 计算重复出现的代码区块占比计算出 clone 分数。并逐一列举重复的代码方便开发者快速定位重复代码将其封装成公共的方法或者组件。 根据上述 5 个维度通过加权平均的方式计算项目质量分并根据木桶效应在计算得分的过程中加大了最低分的权重得出最终项目质量评分。 快来使用 Iceworks Doctor 测测自己项目的得分比比谁的分数高吧~ 问题修复 利用 VS Code 代码提示能力我们在源码中标记出了问题代码辅助开发者快速定位及修复代码。有问题的代码会在代码及文件名上有红色 / 黄色波浪线标示鼠标 hover 时可预览问题详情窗口也可通过 VS Code Problems 栏查看 Errors 列表。方便开发者在更前置的开发过程中发现和修复问题。 点击 “一键修复” 按钮可快速修正问题代码。同时在保存代码时实时检测是否存在有安全风险的代码。 您的数据是私有的 Iceworks Doctor 是开源的你可以很容易地看到我们收集了什么数据。我们永远不会与任何人共享您的个人数据。 前进方向思考 愿景 让团队没有不及格低于60分的代码。 整体方案的设计如下图所示 在后续的版本迭代中Iceworks Doctor 将构建一个完整的系统性方案。仅需安装一个 VS Code 插件便可拥有从配置开发环境辅助开发、诊断和修复质量问题到 PR 发布一整套更加便捷智能的工作流程。通过极低的成本便可维护团队代码质量开发环境、质量、安全问题及团队协作问题均可在 VS Code 中解决并在关键的流程节点来把控代码的质量深度和 DEF 团队合作形成闭环。 同时我们正在筹划淘系前端最佳实践的 ESLint 规范结合 eslint-config-ali 及和各个团队的质量接口人共同制定出更适合淘系前端团队的 ESLint 规范。(欢迎私信我 进行共建哦~) 我们还将为有需要的团队提供研发数据服务支持管理查询项目质量的同时可以配置定制更符合团队需要的质量解决方案及发布卡口发布公告等。 原文链接 本文为阿里云原创内容未经允许不得转载。