好的代码不但能够使得新的项目成员更随意马虎加入项目，同时方便项目组成员快速做好 Back up。好的代码便于促进团队间互换互助提升开拓效率。
代码质量评价标准
有编码履历的人对代码都有一定的“鉴赏力”，能够凭觉得给出代码好坏的主不雅观评价。但是这种凭觉得的办法太过个性随意，所谓仁者见仁智者见智，很难达成共识，那有没有一种公认的标准来鉴定代码质量呢？
答案是有的。这里大略分享当下较常用的评价标准，个中包括：编码规范、可读性、可掩护性、重复度及可测试性。
编码规范紧张包含是否遵守了最佳实践和团队编码规范，是否包含可能出问题的代码，以及可能存在安全的漏洞。编码规范有助于提高团队内帮忙的效率以及代码的可掩护性。
可读性Code Review 是一个很好的测验代码可读性的手段。如果你的同事可以轻松地读懂你写的代码，那解释你的代码可读性很好；反之则解释你的代码可读性有待提高了。遵守编码规范也能让我们写出可读性更好的代码。
可掩护性代码的可掩护性是由很多成分协同浸染的结果。代码的可读性好、简洁、可扩展性好，就会使得代码易掩护；更细化地讲，如果代码分层清晰、模块化好、高内聚低耦合、屈服基于接口而非实现编程的设计原则等等，那就可能意味着代码易掩护。除此之外，代码的易掩护性还跟项目代码量的多少、业务的繁芜程度、利用到的技能的繁芜程度、文档是否全面等诸多成分有关。
重复度遵守 Don’t Repeat Yourself 原则，只管即便减少重复代码的编写，复用已有的代码。对项目定期进行代码重复度检测是一个很故意义的事，可以帮助开拓职员创造冗余代码，进行代码抽象和重构。重复的代码一旦出错，意味着更加的事情量和持续的不可控。如果代码中有大量的重复代码，就要考虑将重复的代码提取出来，封装成公共的方法或者组件。
可测试性代码可测试性的好坏，同样可以反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能解释代码设计得有问题。
除此之外还有很多代码质量评价标准。我们须要一些取舍，选取部分大家有共识的规则定义团队好的代码标准。
代码质量维度当前版本通过 @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 个维度通过加权均匀的办法打算项目质量分，并根据木桶效应，在打算得分的过程中加大了最低分的权重，得出终极项目质量评分。
末了源码、项目地址、获取办法：关注1.编程+开源框架+分布式”等七大口试专栏
2.Java核心知识点1000+Java口试题合集pdf
3.阿里、京东、蚂蚁等大厂口试真题解析
4.Spring百口桶口试题
5.算法条记文档+刷题手册
6.思维导图（jvm、mysql、并发编程、数据库、kafka等等）。
如果你对这个感兴趣，
