本文在团队中共享，预计将列举和分析代码审查中的常见问题，以提高团队的代码规范级别。
在我们的日常工作中，从功能开发到提交代码审查是一个相对普遍的过程。但是，没有审查问题，以及是否有必要修改后代的请求。通常，只有两个或三个审计参与者知道。
为了帮助每个人更好地了解规格并提高代码质量，在这里收集了我们的前端代码审查中的一些常见问题，并进行了一些分析。
主要原因是没有类似于git-flow的合理git工作流程。对于特定绩效，为多人或同一分支的同一分支的同一分支开发。它在发布时没有将测试的测试分开。频率和无限问题通过该功能发布。
以下是某个项目团队的某些代码提交的痛苦，应学习强调重点的要求。
该项目推荐的GIT工作流程：
如果它是从新项目的新分支开发的，请遵循规范格式（项目名称/分支名称），例如DP/Master，该格式有利于统一规格并促进Gerrit审查权限的配置。
值得注意的是，传统的Git-Flow与传统的GIT工作流程不同，它追求新的代码隔离以最大程度地提高最大程度，以避免多种功能条件，但没有采用某些功能，但在线上意外发布。
然而，即使制定了合理的GIT工作流程，我们仍然无法完全防止问题。例如，有人将测试分支合并到了自己的分支机构，例如严格控制代码评论。避免生产事故。
上面列出了上面提到的示例。提交描述尚不清楚，这将直接导致我们不了解该提交所做的事情。如果将来存在问题，它也将增加代码审查的成本。当前推荐的提交格式是：
公司中的一个项目已由commitlint提交，可以参考根目录的.commitlintrc.js文件：
主要原则是描述我们提交的本质以及我们在哪里做。
可以重复使用的常数，方法，规律性，组件等，应从公共场所删除，否则将产生以下问题：
对于上述三张图片中的问题：
持续的
第一组可用于类型判断，第二组可用于中文字段，第三组可用于降落组件。
命名格式遵循完整的写入和线格式。如果将其提供给第三方组件，则可以以第三方组件的格式使用。例如，上述第三组是为元素UI提供的。标签和价值可以在没有资本的情况下使用。
方法，常规，组件等。
公共工具放在SRC/UTILS中。例如，在SRC/UTILS/屏幕上放置了计算导航条高度的方法，定期放置在SRC/UTILS/REGEXPS中，并将公共组件放置在SRC/组件中。
如果您在某些情况下没有想法，例如原始公共模块的修改，则可以咨询原始代码作者和前端团队负责人。
市场上常用的名称规格：
目录名称，文件命名（包括HTML，CSS，JS，图片等）遵循kebab-case。
对于JSX组件，请遵循Pascalcase，包括在其他组件中使用时。
对于模板组件，请遵循Pascalcase或Kebab-Case命名（但需要在项目中统一）。
对于HTML属性，遵循kebab-case的命名，类也可以遵循BEM规范命名。
实际上，命名规格中有许多规则。这里只列出了一些常见的问题，将来将统一组织更详细的命名规格。
如果我们阻止“ play”一词，则没有人能看到用于使用的内容的EventVideo方法。在这里，您可以将其修改为PlayVideo，然后处理根据我们的事件添加手柄的做法。正确的名称应该是正确的名称，应behandleplayvideo。
图2的最初意图是调用以下RMB部门和元转移方法
实际上，方法→Moneyutil有三个以上的问题。即使是此方法的必要性和命名本身也是有问题的，但是在这里需要清楚地定义主要参数名称，这可以使人们一眼看到。
瓦尔以及是否可以统一为金钱和iSfromserver，但Isfromserver仍然不是最佳解决方案。有必要考虑从后端返回的数据，以准确了解方法的意图。
通常，对于命名规格，我们应该首先遵循“代码是注释”。
一些前端学生已经养成了使用==松散比较的习惯。有时，当数据类型不统一时，这确实是一个好方法。
目前，建立了5 =='5'，但这也是由于这种隐藏转换的特征，这将构成错误的隐藏危险，例如：
隐藏转换引起的许多可能性会带来一些不容易找到的错误，因此建议进行严格的比较。如果类型不一致，则可以明确转换，例如ID ===编号（ID）。
上图中有许多嵌套代码层，良好的代码应尽可能平坦，这将有助于阅读和减少潜在错误的可能性。
这个地方的某些巢穴是不必要的，例如验证，API请求可以使用异步/等待，如果可以使用“守护者”，也就是说，如果（！有效）返回false，从而减少代码嵌套。
更复杂的是，我们可以考虑功能分裂，战略模式等。一个核心思想是打开开放和封闭的原理，开放式开放，并关闭修改。通过扩展，优先级优先，而不是通过修改来实现。
原始：https：//juejin.cn/post/7101105014935912485