精华内容
下载资源
问答
  • 2021-06-13 06:49:37

    在项目开发中应用了代码检查工具,这些工具对开发工作的确很有帮助,个人深有体会,写下来,就当做做笔记了。

    前端代码检查分别包括html、css、JavaScript三部分的检查,代码检查需要安装node。

    安装Package Control

    给sublime安装Package Control,Package Control是最佳的sublime插件管理工具,安装过程参考:https://packagecontrol.io/installation

    所有可用的sublime插件:https://packagecontrol.io/

    首先安装SublimeLinter

    其它语法检查插件依赖此插件。

    1.在sublime使用Package Control安装SublimeLinter即可

    2.重启sublime

    安装html检查工具

    参考:https://github.com/mmaday/SublimeLinter-contrib-htmlhint

    1.首先安装node基础插件,在控制台运行:npm install -g htmlhint@latest

    2.在sublime使用Package Control安装SublimeLinter-contrib-htmlhint即可

    3.重启sublime

    安装css检查工具

    参考:https://packagecontrol.io/packages/SublimeLinter-csslint

    1.首先安装node基础插件,在控制台运行:npm install -g csslint

    2.在sublime使用Package Control安装SublimeLinter-csslint即可

    3.重启sublime

    安装JavaScript检查工具

    参考: https://packagecontrol.io/packages/SublimeLinter-jshint

    1.首先安装node基础插件,在控制台运行:npm install -g jshint

    2.在sublime使用Package Control安装SublimeLinter-jshint即可

    3.重启sublime

    编写配置文件

    需要给上述工具编写配置文件,三种类型的文件的代码检查对应的配置文件名依次为:

    .htmlhintrc、.csslintrc、.jshintrc

    三个配置文件需要放在工程目录的最顶层(至少应包含所有需要检测的代码文件),sublime会自动找到这些配置文件并使其生效,如图:

    ae4d24b908a070b82120f84a21b63b7c.png

    具体的配置内容可参考插件所在链接,在这里我仍然给出我现在采用的配置参数,供参考:

    .htmlhintrc

    {

    "tagname-lowercase":true,

    "attr-lowercase":true,

    "attr-value-double-quotes":true,

    "attr-value-not-empty":true,

    "attr-no-duplication":true,

    "doctype-first":false,

    "tag-pair":true,

    "tag-self-close":true,

    "spec-char-escape":true,

    "id-unique":true,

    "src-not-empty":true,

    "title-require":false,

    /*规范类*/

    "doctype-html5":false,

    "id-class-value":false,

    "style-disabled":false,

    "inline-style-disabled":false,

    "inline-script-disabled":false,

    "space-tab-mixed-disabled":false,

    "id-class-ad-disabled":false,

    "href-abs-or-rel":false,

    "attr-unsafe-chars":false

    }

    .csslintrc

    {

    "adjoining-classes": false,

    "box-model": false,

    "box-sizing": false,

    "bulletproof-font-face": false,

    "compatible-vendor-prefixes": false,

    "display-property-grouping": false,

    "duplicate-background-images": false,

    "duplicate-properties": false,

    "empty-rules": false,

    "fallback-colors": false,

    "floats": false,

    "font-faces": false,

    "font-sizes": false,

    "gradients": false,

    "ids": false,

    "import": false,

    "important": false,

    "known-properties": false,

    "non-link-hover": false,

    "outline-none": false,

    "overqualified-elements": false,

    "qualified-headings": false,

    "regex-selectors": false,

    "shorthand": false,

    "star-property-hack": false,

    "text-indent": false,

    "underscore-property-hack": false,

    "vendor-prefix": false,

    "unique-headings": false,

    "universal-selector": false,

    "unqualified-attributes": false,

    "zero-units": false

    }

    .jshintrc

    {

    "node": true,

    "browser": true,

    "esnext": true,

    "bitwise": true,

    "camelcase": false,

    "curly": true,

    "eqeqeq": true,

    "immed": true,

    "indent": 2,

    "latedef": true,

    "newcap": true,

    "noarg": true,

    /*"quotmark": "single",*/

    "regexp": true,

    "undef": true,

    "unused": false,

    "strict": true,

    "trailing": true,

    "smarttabs": true,

    /*如下全局参数根据具体情况进行配置*/

    "globals": {

    "angular": true,

    "$": true,

    "jQuery": true,

    "moment":true,

    "sha1":true,

    "_":true,

    "echarts":true

    }

    }

    使用代码检测工具,以及采用统一配置文件,能帮助团队写出风格统一的代码,提高代码的可维护性,降低bug数量。

    建议可以统一使用HTML-CSS-JS Prettify格式化代码。

    更多相关内容
  • 前端代码审查工具If you are part of a front-end team with several talents (including you), hundreds of commit might be pushed every day. Indeed, no matter the team methodology you use to deliver new ...

    前端代码审查工具

    If you are part of a front-end team with several talents (including you), hundreds of commit might be pushed every day. Indeed, no matter the team methodology you use to deliver new features, each developer is working on a specific functionality.

    如果您是拥有多个才华(包括您)的前端团队的一员,那么每天可能会推动数百次提交。 的确,无论您使用什么团队方法来交付新功能,每个开发人员都在致力于特定的功能。

    In order to validate their changes, a developer should ask for a Merge Request (or Pull Request) to merge these changes into the common branch (the one used for reference). Other front-end developers will make a code review.

    为了验证其更改,开发人员应请求合并请求(或请求请求)以将这些更改合并到公共分支(用于参考的分支)中。 其他前端开发人员将进行代码审查。

    A code review is important for four reasons:

    代码审查很重要,原因有四个:

    • You can check if the code fulfills the specifications.

      您可以检查代码是否符合规范。
    • You are informed about the code modifications, which will potentially lead you to change your modifications on your active branch or suggest some enhancements.

      您将获得有关代码修改的信息,这可能会导致您在活动分支上更改您的修改或提出一些增强建议。
    • It’s a good practice to guarantee a quality code.

      保证质量代码是一个好习惯。
    • It’s a way to share experiences, tips, and coding skills.

      这是一种分享经验,技巧和编码技能的方法。

    Let’s see together what you should inspect in your next front-end code review.

    让我们一起看看在下一个前端代码审查中应检查的内容。

    An image representing a code review colors for changes
    Image source: Author
    图片来源:作者

    To review code changes, we will focus on five main topics:

    为了查看代码更改,我们将重点关注五个主要主题:

    • The quality of the code

      代码质量
    • Efficiency and robustness of the code

      代码的效率和健壮性
    • Are JS framework principles respected?

      是否遵守JS框架原则?
    • GitFlow principles

      GitFlow原理
    • Accessibility (a11y) and internationalization (i18n)

      可访问性(a11y)和国际化(i18n)

    代码质量 (The Quality of the Code)

    The quality level of source code is always difficult to evaluate, especially when it involves several files and, at a broader level, an entire application.

    源代码的质量级别始终很难评估,尤其是当它涉及多个文件,更广泛地说,涉及整个应用程序时。

    Anyway, good code must follow general software development principles, no matter the language. Here are some of them.

    无论如何,良好的代码必须遵循通用的软件开发原则,无论使用哪种语言。 这里是其中的一些。

    DRY和代码分解 (DRY and code factoring)

    If we were asked for the first coding rule in software development that comes into our mind, we surely answer DRY, Don’t Repeat Yourself. It’s a key principle to avoid code redundancy.

    如果我们被问到我们想到的软件开发中的第一个编码规则,我们肯定会回答DRY,不要重复自己。 这是避免代码冗余的关键原则。

    Finding code duplication consists of inspecting the source code and spotting pieces of code that are repeated several times throughout a file or a bunch of files. It may take the form of a constant value, statements, or a set of static values.

    查找代码重复项包括检查源代码并找出在一个文件或一堆文件中重复几次的代码段。 它可以采用常量值,语句或一组静态值的形式。

    Then you can suggest to factor these lines of code with a new file containing static values or helpers/util functions that will be accessible anywhere in the project.

    然后,您可以建议使用一个新文件将这些代码行分解为一个新文件,其中包含可在项目中的任何位置访问的静态值或辅助函数/实用函数。

    Leveraging Javascript Framework’s techniques and features you use is a good habit. Whether you use Angular, React, or Vue.js, each one of them provides tools to factor pieces of code. You should check if a method can be reused as:

    利用Javascript Framework的技术和功能是一个好习惯。 无论您使用Angular,React还是Vue.js,它们中的每一个都提供工具来分解代码段。 您应该检查方法是否可以按以下方式重用:

    In addition, repeated templates can be extracted into a dedicated component or a fragment (if using React) to be reused as much as necessary. This follows the rule of component specialization from React.

    此外,可以将重复的模板提取到专用组件或片段 (如果使用React)中,以根据需要进行重用。 这遵循了React的组件专门化规则。

    有意义的评论 (Meaningful comments)

    Clean code is self-explanatory.

    干净的代码是不言自明的。

    That is why clean code should not contain comments. Variable and method names should be super explicit. In such circumstances, reading code could be similar to reading a book — but that’s not always the case.

    这就是为什么干净的代码不应包含注释。 变量名和方法名应该是超级明确的。 在这种情况下,阅读代码可能类似于阅读书本-并非总是如此。

    Let’s be honest. Every project has its own specificities that should be commented. Meaningful comments are welcome to explain what is going on. But what is a meaningful comment?

    说实话。 每个项目都有其自身的特点,应加以评论。 欢迎发表有意义的评论,以解释正在发生的事情。 但是什么是有意义的评论?

    It should be written over two lines. The first one explains the situation (why do we do what we do). Then the second one indicates the action to face the issue. For example, let’s assume we have to authenticate automatically a user:

    它应该写在两行上。 第一个解释了这种情况(为什么要做我们所做的事情)。 然后第二个指示指出要解决该问题的措施。 例如,假设我们必须自动认证用户:

    // If a network error occurred because no cookie
    // Login again with JWT (JSON Web Token)
    if (err.message.includes('Missing Session token') && jwt) {
    await loginUser(jwt);
    doSomethingElse();
    }

    Plus, seek for commented codes and suppress them! Indeed, it’s a common habit to comment a piece of code to activate it later or to avoid losing it. Frankly, it’s useful 10% of the time, so you can suggest erasing them without a doubt. If they are necessary later, you could refer to the Git history to retrieve the snippet. Deleting these comments will save you time when scrolling and will avoid irrelevant code in files.

    另外,寻找注释的代码并压制它们! 确实,注释一段代码以稍后激活或避免丢失代码是一个普遍的习惯。 坦白地说,它在10%的时间内都是有用的,因此您可以毫无疑问地建议擦除它们。 如果以后需要使用它们,则可以参考Git历史记录来检索代码段。 删除这些注释将为您节省滚动时间,并避免文件中不相关的代码。

    聪明的样式表 (A clever stylesheet)

    CSS is not just a set of rules to give a color to a block of content or to lay out div in the DOM. It comes with some strategies that must be followed in every component of your project.

    CSS不仅仅是一组为内容块添加颜色或在DOM中布置div的规则。 它带有一些必须在项目的每个组件中遵循的策略。

    A clear CSS structure must be set in every template with explicit and meaningful class names. Check if stateful names are used, as an example:

    必须在每个模板中使用明确且有意义的类名称设置清晰CSS结构。 例如,检查是否使用有状态名称:

    <div class="phone-field--is-error">For input with error</div>
    <div class="phone-field--is-success">For input with valid value</div>

    New stylesheet languages such as Sass, Less, and Stylus allow you to create reusable CSS classes, thanks to classes’ combination, variables, and mixins. Using their superpowers will save you time and reduce efforts. Then checking for CSS improvements is a good bet to make reusable layout and appearance for components.

    借助SassLessStylus等新的样式表语言,您可以创建可重用CSS类,这要归功于类的组合,变量和mixins。 利用他们的超能力将节省您的时间并减少工作量。 然后检查CSS的改进是使组件的布局和外观可重用的好选择。

    Another potential check for a clever stylesheet concerns classes’ usage in the template. Indeed, using object syntax for CSS class definition may enhance code readability.

    另一种可能的检查样式表的方法是,在模板中使用类。 实际上,将对象语法用于CSS类定义可以增强代码的可读性。

    Here’s the documentation on object syntax for CSS class definition: Angular, React, Vue.js.

    这是CSS类定义的对象语法文档: AngularReactVue.js

    那单元测试呢? (What about unit tests?)

    We will never stop saying it: A good piece of code is tested with unit tests.

    我们永远不会停止这样说:一段好的代码已经通过单元测试进行了测试。

    These unit tests check every branch the execution could run. It ensures a well-controlled code base and allows you to detect potential regressions quickly when introducing modifications.

    这些单元测试检查执行可以运行的每个分支。 它确保代码库可控,并允许您在引入修改时快速检测潜在的回归。

    Testing is a domain in its own right in computer science. Many key principles from software development should be applied to testing, such as DRY (seen earlier) and KISS (Keep It Stupid and Simple).

    在计算机科学中,测试本身就是一个领域。 软件开发中的许多关键原则应应用于测试,例如DRY(较早见过)和KISS(保持愚蠢而简单)。

    Unit test libraries like Jest, Mocha, Chai, and Jasmine provide plenty of methods to ease unit tests. If you want to extend your test battery with e2e (end-to-end) integration tests, Cypress, with a super friendly and intuitive GUI, is a good bet.

    JestMochaChaiJasmine这样的单元测试库提供了许多简化单元测试的方法。 如果您想通过e2e(端到端)集成测试来扩展测试电池, 赛普拉斯具有超级友好和直观的GUI,是一个不错的选择。

    A basic verification could be to check if a test setup or post-clean statements are not repeated several times. beforeEach and afterEach are appropriate methods to respectively prepare and post-clean the playground (provided by unit testing frameworks).

    一个基本的验证可能是检查测试设置或清洗后声明是否没有重复几次。 beforeEachafterEach是分别准备和清理操场的适当方法(由单元测试框架提供)。

    Test naming has also its importance. A good practice regarding naming is to select one of the following techniques, and stick to it:

    测试命名也很重要。 有关命名的一个好的实践是选择以下技术之一并坚持使用:

    it('SHOULD do something WHEN myVariable is true')# ORmyMethod_SHOULD_return_true_WHEN_myVariable_is_true()

    守则的效率和稳健性 (Efficiency and Robustness of the Code)

    Efficiency and robustness of the code are the main keys to getting a well-controlled and bug-free code base. It’s based on the coding habits and skills of developers, which come with experience.

    代码的效率和健壮性是获得可控且无错误的代码库的主要关键。 它基于开发人员的编码习惯和技能,并附带经验。

    处理意外值 (Handle unexpected values)

    Even though you are 101% sure that a value will always be defined or have an expected value, this won’t be the case at some point in your project. Indeed, projects and applications evolve, and some unexpected values might appear.

    即使您101%确信将始终定义值或具有期望值,但在项目中的某些时候情况并非如此。 实际上,项目和应用程序会不断发展,并且可能会出现一些意想不到的价值。

    That is why it’s important to prevent these situations from happening by doing the following:

    因此,通过执行以下操作来防止发生这些情况很重要:

    • Check for null or undefined values in object properties. If you’re using Typescript or Babel’s optional chaining, it’s super easy with ? syntax.

      检查对象属性中的nullundefined值。 如果您使用的是TypescriptBabel的可选链接 ,那么使用超级简单? 句法。

    • Ensure a default case is provided when using the switch-case statements to handle unexpected values.

      使用switch-case语句处理意外值时,请确保提供了default大小写。

    • Do the same as above for the if — else if — else conditional instructions.

      对于if — else if — else有条件的指令,请执行与上述相同的操作。

    使条件语句清晰易读 (Make conditional statements clear and readable)

    Efficient verification and a clear logic in the conditional instructions will help make for readable code.

    有效的验证和条件指令中清晰的逻辑将有助于使代码更易读。

    Then, ensure there is a rational and logical way in conditions. Maybe the verification is too complicated, maybe it’s not enough safe…

    然后,确保条件中存在合理和逻辑的方式。 验证可能太复杂了,也许不够安全……

    Suggest the creation of a dedicated method to make the condition more readable. Plus, it could be reused elsewhere.

    建议创建专用方法以使条件更易读。 另外,它可以在其他地方重用。

    分解组件 (Factorizing components)

    It’s quite common to find similar templates in several components or in a single component template. A good practice is to extract this code into a specialized component or a reusable template.

    在多个组件或单个组件模板中找到相似的模板是很常见的。 一个好的做法是将这些代码提取到专门的组件或可重用的模板中。

    Angular provides ng-template or ng-container elements to create reusable templates.

    Angular提供ng-templateng-container元素来创建可重复使用的模板。

    React, by definition, is prone to create new specialized components. If you prefer reusable templates, you can find a way in the article “How to Build Reusable Layouts in React JS.”

    根据定义,React倾向于创建新的专用组件。 如果您喜欢可重用模板,则可以在文章“ 如何在React JS中构建可重用布局 ”中找到一种方法。

    Vue.js does not offer such things, but you could either create a dedicated component or follow the advice of Anthony Gore in his article “Extending Vue Component Templates.”

    Vue.js不提供此类功能,但是您可以创建一个专用组件,也可以遵循Anthony Gore在他的文章“ 扩展Vue组件模板 ”中的建议。

    是否遵守JS框架原则? (Are the JS Framework Principles Respected?)

    JS frameworks are unavoidable now when it deals with creating dynamic and user-friendly web applications. They are a game changer in the front-end development world. Each framework comes with its own principles, rules, and conventions. Thus, you need to check if these standards are respected.

    现在,JS框架在处理创建动态且用户友好的Web应用程序时不可避免。 他们是前端开发世界中的游戏规则改变者。 每个框架都有其自己的原理,规则和约定。 因此,您需要检查这些标准是否得到遵守。

    命名约定 (Naming convention)

    Naming conventions should be respected so that it allows identification of the content of the file’s or variable’s purpose.

    应遵守命名约定,以便可以识别文件或变量用途的内容。

    Here is a non-exhaustive list of checks for each framework:

    这是每个框架检查的非详尽清单:

    Angular (more details here)

    Angular ( 更多详细信息在这里 )

    • filenames are suffixed with component, directive, filter, service or module

      文件名后缀有componentdirectivefilterservicemodule

    • Observable variables starts with a $

      可观察变量以$开头

    • private parameters in class constructor are prefixed with an underscore

      类构造函数中的私有参数以下划线为前缀

    React (more details here and here)

    React ( 此处此处有更多详细信息)

    • Use PascalCase for React components and camelCase for component instances

      将PascalCase用于React组件,将camelCase用于组件实例
    • Avoid using DOM component prop names for different purposes

      避免将DOM组件属性名称用于不同目的

    Vue.js (more details here)

    Vue.js ( 此处有更多详细信息 )

    • Component filename and name are “pascal-cased” (e.g., MyComponent.vue)

      组件的文件名和name是“用小写字母括起来的”(例如, MyComponent.vue )

    • Functions or variables from Vue instance starts with a $ (e.g., this.$route or this.$emit), therefore it’s a good practice not to add custom functions or variables starting with this character.

      Vue实例中的函数或变量以$开头(例如, this.$routethis.$emit ),因此,最好不要以此字符开头添加自定义函数或变量。

    生命周期挂钩,数据流和访问器 (Lifecycle hooks, data flow, and accessors)

    JS frameworks are built according to several lifecycle hooks that rule the component state and behaviour. They need to be used appropriately to avoid unexpected infinite loops or memory leaks.

    JS框架是根据几个生命周期挂钩构建的,这些挂钩决定了组件的状态和行为。 需要适当使用它们以避免意外的无限循环或内存泄漏。

    For example, in Angular, you need to check when using Subscriptions if the beforeDestroy lifecycle hook is unsubscribing all subscriptions by calling the unsubscribe method.

    例如,在Angular中,您需要在使用“ Subscriptions时检查beforeDestroy生命周期挂钩是否通过调用unsubscribe方法取消订阅所有订阅。

    In Vue.js, the beforeRouteEnter guard (or any route guards) should, in the end, call the next method to navigate through. This concerns Angular guards too.

    在Vue.js中, beforeRouteEnter保护(或任何路由保护)最后应调用next方法进行导航。 这也与Angular守卫有关。

    In React, you should check for the usage of componentWillMount and componentWillUpdate lifecycle methods, which are now deprecated because of misunderstanding.

    在React中,您应该检查componentWillMountcomponentWillUpdate生命周期方法的使用情况,由于误解,这些方法现在已过时

    render method is mandatory in a class component. It mustn’t modify component state. Further details may be found here.

    render方法在类组件中是必需的。 它不能修改组件状态。 可以在此处找到更多详细信息

    In Vue.js again, you should check for data property changes in computed, which is a main anti-pattern practice. Computed properties are just meant to be data accessors and not to update values. This could be applied to Angular getters.

    在Vue.js再次,你应该检查data的属性更改computed ,这是一个主要的反模式的实践。 计算属性仅是作为数据访问器,而不是更新值。 这可以应用于Angular getters

    GitFlow原理 (GitFlow Principles)

    If you are not familiar with this term, the GitFlow means the strategy you have set to manage several versions of the same code base. There is a reference branch and many copies of it with their specificities.

    如果您不熟悉此术语,则GitFlow表示您已设置用于管理同一代码库的多个版本的策略。 有一个参考分支,并且有很多分支及其特殊性。

    Common rules must be applied regarding this strategy and must be followed to avoid code loss or conflicts. The GitFlow must be respected in every code review.

    必须对此策略应用通用规则,并且必须遵循这些规则以避免代码丢失或冲突。 在每次代码审查中都必须尊重GitFlow。

    每次提交都不应破坏应用程序 (Every commit shouldn’t break the app)

    This is more advice than a check for the code review. Indeed, every single commit mustn’t introduce building time or runtime errors.

    这比检查代码检查更多的建议。 实际上,每个提交都不得引入构建时间或运行时错误。

    If for any reason you need to roll back to a specific commit and this one fires troubleshoots, it will put a mess in all the source code.

    如果出于某种原因您需要回滚到特定的提交并且此操作引发了故障排除,则会使所有源代码陷入混乱。

    That is why it’s a better way to commit frequently with tiny but controlled and clear changes.

    这就是为什么这是一种更好的方法,可以频繁地进行微小但可控且清晰的更改。

    检查涉及的分支 (Check the involved branches)

    It’s not a surprise that a merge request involves two branches: the one containing changes and the reference branch.

    合并请求涉及两个分支也就不足为奇了:一个分支包含更改和引用分支。

    It’s a good idea to check both of them. Indeed, as we have no restriction on creating branches, a mistake might be easily introduced. This may come from various reasons:

    最好将它们都检查一下。 实际上,由于我们对创建分支没​​有任何限制,因此很容易引入错误。 这可能来自多种原因:

    • wrong reference branch (for example, if there is a sub-branch)

      错误的参考分支(例如,如果有子分支)
    • spelling error

      拼写错误
    • duplicated branch to merge (if a copy of the branch to merge has been created for any reason)

      要合并的分支重复(如果出于任何原因创建了要合并的分支的副本)

    Two good practices to avoid introducing unwanted pieces of code are:

    避免引入不需要的代码段的两种良好做法是:

    • Name the feature branch explicitly by prefixing a ticket number (if you use a ticketing platform such as GitLab, GitHub, JIRA, or Azure DevOps Services)

      通过添加票证编号来明确命名功能分支(如果使用票务平台,如GitLabGitHubJIRAAzure DevOps Services )

      Example:

      例:

      287-add-tracking

      287-add-tracking

    • Merge your reference branch into the branch to merge first. This will help to detect potential errors and conflicts in the local branch. Thus, the reference branch is protected and the merge will be controlled.

      将您的参考分支合并到该分支中以首先进行合并。 这将有助于检测本地分支中的潜在错误和冲突。 因此,参考分支受到保护,合并将受到控制。

    在本地测试分支 (Test the branch locally)

    This is a zealous practice but it should be a reflex. Testing the branch locally by checking it out is a nice-to-have habit.

    这是一种热情的做法,但应该是一种反思。 通过检出本地测试分支是一个好习惯。

    Using the simple command git checkout my-feature-branch-to-test and running the app will allow you to detect errors locally when building the app. Of course, it will be a handy way to verify if the specifications have been fulfilled.

    使用简单的命令git checkout my-feature-branch-to-test并运行应用程序,可以使您在构建应用程序时在本地检测错误。 当然,这将是验证规格是否已满足的便捷方法。

    Yet let’s be honest: This costs time, and in a world in which time-to-market must be as short as possible, this practice is often dropped out.

    但说实话:这会浪费时间,而且在这个产品上市时间必须尽可能短的情况下,这种做法经常会被放弃。

    可访问性(a11y)和国际化(i18n) (Accessibility (a11y) and Internationalization (i18n))

    Think broadly! A web app may be visited by a large part of the population, including people from all over the world. Including people with visual, motor, and other impairments by adding a few attributes in your code will change the experience you provide them.

    广泛考虑! Web应用程序可能会被包括世界各地的人在内的大部分人访问。 通过在代码中添加一些属性来包括视觉,运动和其他功能障碍的人,将会改变您为他们提供的体验。

    Accessibility (a11y) and internationalization (i18n) have become key concepts in front-end development. If these features don’t ring a bell with you, you can refer to my previous article “The Front-End Features You Might Have Missed,” User Experience section.

    可访问性(a11y)和国际化(i18n)已成为前端开发中的关键概念。 如果您不满意这些功能,可以参考我以前的文章“ 您可能会错过的前端功能” ,“用户体验”部分。

    辅助功能属性 (Accessibility attributes)

    You should ensure the presence of a11y attributes such as:

    您应确保存在以下所有属性:

    i18n键 (i18n keys)

    A single commit involves many perspectives (including HTML templating, CSS styling, testing, and components), and forgetting a translation may occur — especially when you manage several languages.

    一次提交涉及多个角度(包括HTML模板,CSS样式,测试和组件),并且可能会忘记翻译-尤其是当您管理多种语言时。

    Therefore, do not forget to check if each translation has its match for each language. Plus, a translation may be used in a template but does not correspond to an existing key.

    因此,不要忘记检查每种翻译是否与每种语言相匹配。 另外,翻译可以在模板中使用,但不对应于现有键。

    It seems a boring task, but the devil hides in the details, does it?

    这似乎很无聊,但是魔鬼隐藏在细节中,对吗?

    利用您使用的i18n库 (Leverage the i18n library you use)

    You can do incredible things with your i18n library.

    您可以使用i18n库执行令人难以置信的事情。

    They are getting more and more polyvalent and provide powerful functionalities. You can handle:

    它们越来越多价并提供强大的功能。 您可以处理:

    • Pluralization

      多元化
    • Date and number formatting

      日期和数字格式
    • HTML templating

      HTML模板
    • Translations lazy loading

      翻译延迟加载

    Do not hesitate to over-use it, especially about conjugation (be, is, are, was, were, been), or to add a CSS class on a particular word of a sentence. The goal is to make your translations as much reusable as possible.

    不要犹豫,过度使用它,特别是关于结合( 一直 ),或者对一个句子的特定单词添加CSS类。 目的是使您的翻译尽可能地可重用。

    Leveraging a i18n library will save you time and effort. It’s worth it instead of reinventing the wheel!

    利用i18n库可以节省您的时间和精力。 值得而不是重新发明轮子!

    结论 (To Conclude)

    Reviewing merge requests may take a lot of time, but it’s a good practice to get used to. It allows you to get informed of changes other developers introduce to the code base. In addition, it’s a different way to share programming language tricks, front-end development insights, and experiences.

    审核合并请求可能会花费很多时间,但这是习惯的好习惯。 它使您可以了解其他开发人员对代码库所做的更改。 此外,这是共享编程语言技巧,前端开发见解和经验的另一种方式。

    In the end, the time spent in reviewing will be a good bet for the future since the earlier you set good coding practices, the earlier time spent to review will be shortened. It’s an investment in the future… in some ways.

    最后,花在审查上的时间将是未来的好选择,因为您越早设置好的编码实践,就可以缩短花在审查上的时间越早。 在某些方面,这是对未来的投资。

    翻译自: https://medium.com/better-programming/what-you-should-inspect-in-a-front-end-code-review-4010e1bc285a

    前端代码审查工具

    展开全文
  • 提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 文章目录前言一、pandas是什么?...示例:pandas 是基于NumPy 的一种工具,该工具是为了解决数据分析任务而创建的。 二、使用步骤 1.引入库 代码

    正经学徒,佛系记录,不搞事情

    前言

    使用此插件的目的很单纯,就是为了更快的通过IDE工具进行代码审查

    优势

    在现在互联网公司的Workflow工作模式下,开发的代码需要提交merge request(MR)给同事进行代码审核,以往通过gitlab网站直接查看的代码变更的方式,个人认为主要有这几个缺点

    1. 大文件(不是文件体积大,是代码修改行数多)会自动收缩,且打开会卡顿
      在这里插入图片描述
    2. 无法快速跳转
      如想查看getCurrentContactGroupId的实现,但不能直接快捷键跳过去
      在这里插入图片描述
    3. 不会有校验提示,如单词写错

    那相反的使用vscode插件就能通过IDE的优势来查看代码,即有代码高亮,波浪线纠错,又能在方法之间跳转,方便审查代码逻辑

    使用

    话不多说开始使用
    官方地址:https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow

    1. 下载

    可直接在vscode中搜索下载
    在这里插入图片描述

    2. gitlab生成access token

    这一步的目的,是为了生成一个能够访问仓库权限的token

    在这里插入图片描述

    在这里插入图片描述
    至少选中 apiread_user 权限,可以设置有效期
    点击生成token一定要复制下来出于安全考虑,以后都不会在看到这个token
    在这里插入图片描述

    3. 配置vscode

    在vscode快捷键打开 Cmd+Shift+P.
    输入

    GitLab: Set GitLab Personal Access Token
    

    在这里插入图片描述
    然后输入公司gitlab的域名后回车

    https://git.xxx.com
    

    再粘贴access token回车,即可在左侧看到gitlab的效果
    在这里插入图片描述

    4. 结合gitlabMR使用

    最后将需要自己review的MR上配置上自己的账号即可直接在vscode中实时查看当前正在review的MR
    在这里插入图片描述

    最后的最后特别强调一下,gitlab如果需要升级付费版本才能享受一个MR支持多个人同时review,否则一次只能将一个人设置成Reviewer,毕竟大家都要赚钱

    展开全文
  • Gerrit是一个基于Git项目的代码审查和项目管理工具。 Gerrit允许任何授权用户向主Git存储库提交更改,从而简化了基于Git的项目维护,而不是要求所有已批准的更改由项目维护者手动合并。 Gerrit利用网页浏览器,使同...
  • 点击上方前端Q,关注公众号回复加群,加入前端Q技术交流群中大型公司中前端项目往往不止一个,前端开发人员多加上前端项目众多,为了维持一定的项目团队风格往往十分艰难。这篇文章主要是在公司中针...

    点击上方 前端Q,关注公众号

    回复加群,加入前端Q技术交流群

    中大型公司中前端项目往往不止一个,前端开发人员多加上前端项目众多,为了维持一定的项目团队风格往往十分艰难。这篇文章主要是在公司中针对组内现状问题进行问题收集、调研、开发、落地的总结。

    1. 前端项目现状

    前端组内项目众多,但是在代码质量检测方面一直不统一。比如像xx系统和移动端项目都有简单 lintrc 配置、但都是重复复制的配置;像 node 方向的项目几乎只是简单配置了几个规则;而内部yy系统的项目全部都没有配置代码检测、导致 CR 的时候需要重复性提出相关代码风格问题;除此之外针对新开的项目大部分是手动新建文件并把配置复制一份过来,重复冗余且效率低下。

    2. 相关问题、如何解决

    鉴于以上现状,各个项目相关检测配置不统一也不便于管理。结合现有的前端代码检测工具及组内项目现状,考虑配置一份通用性规则,里面集合了不同规则集,不同项目引入不同的规则集扩展。我们只需要维护这个包项目及规则本身即可,每个项目 install 下载即可使用。这样的做法可以带来多种好处:

    • 统一团队里面成员的编码风格,使代码风格统一

    • 提高代码的可读性,像一些风格上的问题如换行等等会让代码更难读懂

    • 提高项目的代码质量、提高开发效率,Lint很容易发现低级的、显而易见的错误,提前发现可以减少由于语法问题带来的线上问题且节省排查定位问题消耗的时间

    一. lint相关工具介绍及意义

    1. JSLint

    JSLint 的核心是 Top Down Operator Precedence(自顶向下的运算符优先级)技术实现的 Pratt 解析器。在不断发展过程中,由于 JSLint 中的所有规则都由开发者定义个人风格过于明显,若要使用就要接受其定义的所有规则,这就导致新的 Lint/Linter 工具诞生。

    2. JSHint

    JSHint 基于 JSLint、其核心实现仍然基于 Pratt 解析器的基础上,但解决了很多 JSLint 暴露出来的缺点,比较明显的就是可添加可配置的规则,用参考文章中的一句话描述:“ JSHint 的出现几乎是必然的,前端开发者日益增长的代码质量诉求和落后偏执的工具之间出现了不可调和的矛盾”。

    3. JSCS 和 ESLint

    ESLint 和 JSCS 几乎在同一时段发布,且两者都是利用 AST 处理规则,用 Esprima 解析代码,因为需要将源码转成 AST,执行速度上其实是输给了 JSHint;ESLint 真正能够火的原因其实是 ES6 的出现,ES6 新增许多新语法,但是 JSHint 本身的一些设计原因无法兼容新语法,而 ESlint 由于其高扩展性,既能扩展自定义规则又能通过babel-eslint 更换掉默认解析器,对新框架的语法也能很好的兼容,所以最终 ESlint 被广泛使用;又由于 JSCS 和 ESLint 实现原理大同小异,再维护也没有太大的意义,最终 JSCS 与 ESLint 合并。

    84b48213abdc8072c69b64eab94b937e.png
    image.png

    4. Prettier

    Prettier 也是一个代码样式检查优化的工具,但其可配置的规则很少,除了少部分可配置的规则外,其他都不可更改以此来达到强制性统一代码风格的目的。Prettier 与 ESlint 不同,如下图所示,它不止适用于 JS 代码,还适用于其他前端常用语言,不过它的规则只针对代码样式(Formatting) 而不针对于代码质量(Code-quality) 。Prettier可以单独在项目中使用,也可以与 ESlint 一起搭配使用。

    a99226d297a9e3c7c0a68fe0aac1ffac.png
    image.png

    二. 项目配置ESLint

    1. 安装和使用 ESLint

    1.1 文件中对应代码开启/关闭对应规则

    执行命令 npm install eslint \--save-dev 安装之后,可以直接在项目源码中针对对应的代码块开启规则:

    /* eslint console: "error" */ 
    console.log('66666')
    复制代码

    也可以在代码块中直接禁用相关规则:

    1. 被包裹的代码块中取消eslint检查,也可以带上对应的规则表示仅禁用对应规则
    /* eslint-disable */
    alert(‘foo’); 
    /* eslint-enable */
    
    2. 针对某一行禁用eslint检查:
    alert(‘foo’); // eslint-disable-line
    
    // eslint-disable-next-line no-alert 
    alert(‘foo’);
    复制代码

    1.2 配置文件中开启/关闭规则

    执行 npm install eslint \--D 全局安装ESlint之后,使用命令 eslint \--init 初始化 eslint 配置文件,执行过程中会询问一些配置化的问题,可以根据自己的需求去进行选择:

    505bd93df92ffd2be8e0257c3e92fb0b.png 选择结束之后最终会生成一份初始化 .eslintrc 文件如下所示:

    module.exports = {
      env: {
        browser: true,
        es6: true,
      },
      extends: [
        'plugin:vue/essential',
        'airbnb-base',
      ],
      globals: {
        Atomics: 'readonly',
        SharedArrayBuffer: 'readonly',
      },
      parserOptions: {
        ecmaVersion: 2018,
        sourceType: 'module',
      },
      plugins: [
        'vue',
      ],
      rules: {},
    };
    复制代码

    2. ESLint 文件配置参数介绍

    Tips:建议还是直接看英文翻译,有的查阅中文意思根本就翻译错了

    ESLint配置参数文档:eslint.org/docs/user-g…[1]

    eslintrc文件中的配置参数非常多,大部分参数官方文档都有相关的说明,这里只针对此次使用中一些比较重要的参数进行罗列:

    • root:将其设置为 true 之后,ESLint 就不会再向上去查找文件检测(后续两份rc有贴测试结论)

    • impliedStrictecmaFeatures 中的 impliedStrict 设置为 true 之后就可以在整个项目中开启严格模式

    • env:指定启用的环境,通常开启的是 browser 环境和 node 环境

    • plugins:引入的相关插件名,可以直接省略 eslint-plugin- 前缀

    • extends:extends 中可以直接引入可共享配置包,其中也可以直接省略包名前缀 eslint-config-,其中还可以直接引入基本配置文件的绝对路径或相对路径

    • rules:参数 rules 中可以设置很多 eslint 内置的规则,官方文档中规则前面有个修补图标9e1e2dc516c6dc71d687b57f3200d27d.png的表示在检测的时候可以自动修复规则,反之会报 error 且需要自己手动修复。rules 属性中的规则都接收一个参数,参数的值如下:

    "off" 或 0:关闭规则
    "warn" 或 1:开启规则,黄色警告 (不会导致程序退出)
    "error" 或 2:开启规则,红色错误 (程序执行结果为0表示检测通过;执行结果为1表示有错误待修复)
    复制代码

    有的规则开启后还可以配置额外的参数项,可以根据不同的情况开启规则后再添加额外的参数项。

    3. 命令行参数介绍

    ESLint命令行参数文档:eslint.cn/docs/user-g…[2]

    eslint 相关的命令行设置也可以直接参考官方文档,一般是在 package.json 文件中对 eslint 进行特定的命令行设置,用来达到执行对应命令呈现不同效果的目的。命令行中主要用到的是 global 语法,这里也只针对此次使用过程中个别参数进行介绍:

    • --ignore-path: 后面跟上对应的文件名,当 eslint 检测文件的时候会忽略检测此文件

    • --fix: 配置这个参数之后,执行命令时针对可以自动修复的问题就会直接被修复,如果不希望执行时进行自动修复可不配置

    • --rulesdir: 引用本地开发规则路径

    三. 自定义规则集

    当我们知道了怎么在项目中简单配置相关的检测规则之后,就会碰到开头所说的问题,重复性的配置、重复的复制粘贴这样会导致效率低下且代码冗余不便于统一管理。eslint 的高扩展性可以让我们很方便的做很多事:比如把通用性的配置整合成一个可共享配置包,这样我们只需要把通用性的一些规则分类整理并发布成为一个 npm 包,其他项目只需 install 下载后配置好规则即可生效。

    1. 共享配置包 eslint-config-zly 整体结构

    共享配置包主要是将一些配置导出,使用方直接引入即可,在此参考了一些比较出名的 eslint-config 类似 airbnb 和 alloy。

    1.1 参考 airbnb

    airbnb源码:自行搜索 github 寻找源码

    最开始看的是目前前端社区中使用最火的 airbnb,airbnb 主要是在 package 文件中分别建了两份配置,eslint-config-airbnb 中主要是 react 的一些规则配置,eslint-config-airbnb-base 主要是基本规则配置分类。

    3d93814ca4753e142037d6bb01165003.png
    image.png

    由于 eslint 对于 config 配置包没有提供对应的模版,所以在参照了 airbnb 目录结构之后开始手动新建不同分类的文件,将一些内置规则按照 eslint 中 rules 模块介绍中不同功能块进行划分,然后在 .eslintrc.js 文件中通过 extends 相对路径引入。但是由于 airbnb 他们项目本身使用的技术栈比较简单所以按照这样发布两个包也没什么问题,如果多项目多技术栈按照这样去发包的话则需要管理发布多个包。

    847b530047bae08e91139bba3f4a56da.png
    image.png

    1.2 参考 alloyTeam

    alloy源码:github.com/AlloyTeam/e…[3]

    由于 airbnb 其分开发布的结构方式用在我们的设计上不是很适合,于是看了一下 alloy 部分的源码。alloy 中将一些样式相关的规则给了 Prettier 管理,内部主要是 React/Vue/TypeScript 插件中的一些规则分别列在跟目录的 base.js、vue.js、react.js、typescript.js 文件中,通过文档、示例、测试、网站等方便大家参考 alloy 的规则,并在此基础上做出自己的个性化,且其内部利用 travis-ci 高度的自动化,将一切能自动化管理的过程都交给脚本处理,其通过自动化的脚本将成很多个 ESLint 配置文件分而治之,每个规则在一个单独的目录下管理。参考了 alloy 的目录结构之后,我们将 eslint-config-zly 项目结构进行了调整,主要是 base 规则和 vue 规则放在同一集目录下:

    db57e3e89a7302a3315631b147b70f4f.png
    image.png

    2. 发包设计

    因为最终是要发布到npm上,所以结合之前的一些参考项目的源码结构、对于如何发包管理进行了一部分的讨论,主要是针对于最终的包怎么发布以及项目使用时怎么引入,其中主要发包设计有如下几种:

    2.1 发布多个包,组合使用

    主要也是不同规则单独发一个包,需要组合使用的放在 extends 中一起使用即可。这个主要是发包管理过多,组合使用也不够直接方便,故弃用。

    extends: [airbnb/base, airbnb/base]
    复制代码

    2.2 发布多个包,无组合使用:

    类似于 airbnb,不同功能的规则单独作为一个 npm 包发布,需要的时候单独下载引入。这个可以满足让业务方想用哪种类型的规则就引入哪个包的期望,但是这个包管理发布的话需要一个个维护,比较麻烦、也不符合我们的预期。

    参考:https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb-base/README.md
    
    extends: airbnb/base
    extends: airbnb/vue
    
    一个项目中根据不同分类发布不同的包,如 airbnb 中项目 base 集模块单独发包 eslint-config-airbnb-base,
    需要 base 的单独引入这个包即可
    复制代码

    2.3 只发布一个包,组合使用

    类似于上述 alloy,将通过不同文件夹将功能划分清楚,例如 base 只装基础规则、vue 只装 vue 规则,如果两者规则都需要的就组合使用,但是由于我们希望使用的业务方可以直接使用一个集中的规则集而不需要手动组合,所以这个方案有点不符合我们的预期。

    参考:https://github.com/AlloyTeam/eslint-config-alloy/blob/HEAD/README.zh-CN.md
    
    extends: alloy/base,
    extends: alloy/vue,
    extends: alloy/typescript
    
    需要组合使用的话就 extends: [alloy/base, alloy/vue]
    复制代码

    2.4 只发一个包,无组合使用

    综合考虑前面两种发包设计的优劣,再结合我们的需求,于是选择第三种方案,所有规则都在一个包里面管理,base 集作为基础规则集会在每个其他规则集中引入,其他类似 vue 集会在引入 base 集后叠加 vue 的规则,业务方需要使用的话直接引入 vue 集时基础规则和 vue 规则都会生效。

    extends: zly/vue
    extends: zly/react
    extends: zly/tina
    extends: zly/node
    
    vue 的项目就单独引入 zly 包的 vue 集, node的项目就单独引入 zly 包的 node 集
    复制代码

    3. 规则集

    定好大概的项目架构之后相当于架子搭建好,下一步就是内容填充了。主要是针对于不同的框架语法要用不同的规则集进行检测,结合公司现有项目制定了一下规则集:

    - 'best-practices.js'
    - 'custom.js'
    - 'errors.js'
    - 'es6.js'
    - 'import.js'
    - 'tyle.js'
    - 'variables.js'
    复制代码

    最后在 _base 文件下面 index.js 将上述文件与 airbnb-base 包一起作为 extends 引入:

    Tips:在整理 node 集的时候发现 node 项目需要在严格模式下开发,ecmaFeatures 中 impliedStrict 设置为 true 即项目都处在严格模式下,无需写上 'use strict',刚开始只想把这个配置写在 node 集中,最后商讨后还是放在 base 集中,确定所有用到的项目都严格模式下。

    module.exports = {
      parserOptions: {
        ecmaFeatures: {
          impliedStrict: true,
        }
      },
      extends: [
        'airbnb-base',
        join(__dirname, './rules/best-practices'),
        join(__dirname, './rules/errors'),
        join(__dirname, './rules/es6'),
        join(__dirname, './rules/import'),
        join(__dirname, './rules/style'),
        join(__dirname, './rules/variables'),
        join(__dirname, './rules/custom'),
      ],
    }
    复制代码

    3.2 vue集

    vue 规则集中主要是引入了 eslint-plugin-vue 中 vue3-recommended,_base集,再针对特定的规则进行配置:

    module.exports = {
      env: {
        browser: true,
      },
      extends: [
        'plugin:vue/vue3-recommended',
        join(__dirname, '../_base/index'),
        join(__dirname, './rules/vue'),
      ],
      parserOptions: {
        parser: 'babel-eslint',
      },
      plugins: ['vue'],
    }
    复制代码

    3.3 tina集

    tina 规则主要是针对小程序项目,用的也是 vue 语法,这里针对于是引入 vue 规则集还是直接引入 eslint-plugin-vue 做了一部分讨论,最终还是决定直接引入 vue 集针对不必要的规则手动在 tina 集中关闭:

    module.exports = {
      globals: {
        App: true,
        Page: true,
        wx: true,
        getApp: true,
        getPage: true,
        getCurrentPages: true,
      },
      extends: [
        join(__dirname, '../vue/index'),
        join(__dirname, './rules/tina'),
      ],
      parserOptions: {
        parser: 'babel-eslint',
      },
    }
    复制代码

    3.4 node集

    node 集制定过程中,看了 eslint-config-node、eslint-config-egg、eslint-plugin-eggache 和 eslint-plugin-node,经过对比发现 eslint-plugin-node 插件中制定的node规则最多最纯粹,且社区中 eslint-plugin-node 使用较多提供的解决方案也比较多,所以经多方调研最后决定 eslint-plugin-node。node 集中用了 eslint-plugin-node 中 recommended,再引入 _base 集,最后针对特定的 node 规则在 rules/node/index.js 中做特殊处理。

    module.exports = {
      env: {
        node: true,
      },
      extends: [
        'plugin:node/recommended',
        join(__dirname, '../_base/index'),
        join(__dirname, './rules/node')
      ],
      plugins: ['node'],
    }
    复制代码

    针对上述除 _base 以外的规则集中,其他 extends 的顺序都是先引入第三方插件规则,再引入 _base 规则,然后最后引入自己针对性规则修改过的文件。

    四. 自定义插件

    ELSint自定义规则及源码解析juejin.cn/editor/draf…[4]

    定好项目架构、发包设计、规则集之后,想要整合浩哥的自定义规则 "_.get禁止第三参数 " 的时候,发现 eslint 自定义配置包中不能集成自定义规则,只有自定义插件才可以集成自定义规则,于是整体项目从 config 过渡到 plugin。

    1. 使用模版初始化配置

    Yeoman generator-eslint:yeoman.io/authoring/[5]

    ESLint 官方为了方便开发者开发插件有提供 Yeoman 模版 generator-eslint,基于官方提供的模板可以快速创建 ESLint Plugin 项目, 按照如下步骤进行初始化:

    npm i -g yo
    npm i -g generator-eslint
    // 创建一个plugin
    yo eslint:plugin
    // 创建一个规则
    yo eslint:rule
    复制代码

    初始化的项目目录结构如下:

    • rules 文件夹存放的是各个规则文件

    • tests 文件夹存放的是单元测试文件

    • package.json 是 ESLint 插件 npm 包的说明文件,其中的 name 属性就是 ESLint 插件的名称,其命名规则为:eslint-plugin-*

    447acbdfd87d17d2e8da531ebeeabd8e.png
    image.png

    2. 整合自定义规则

    lib 文件夹中的 config 下放之前定义好的自定义规则集分类,rules 文件夹下放相关的自定义规则分类,把下篇文中针对性写的 _.get() 禁止第三参数的自定义规则放在 rules 中的 lodash-get.js 文件下且在 index.js 中引入:

    7065036af93af86332017ce1898028f0.png
    image.png

    3. 本地测试

    如果你的 npm 包还没发布,需要进行本地调试,可使用 npm link 本地调试。在 eslint-plugin 项目中执行 npm link 命令,就可以全局使用 eslint-plugin 命令了,然后可以在你的测试项目中执行 npm link eslint-plugin,引入测试即可。在 npm 包文件夹下执行 npm link 命令,会创建一个符号链接,链接全局文件夹 {prefix}/lib/node_modules/ 和你执行 npm link 的包文件夹。

    注意:package-name 是 package.json 中的 name, 而不是文件夹名。

    五. 代码提交检测优化

    1. git hooks

    git hooks 即 git 在执行过程中的钩子,其可以触发自定义脚本。每个含有 repository 的项目下都存在一个.git 文件、每个.git 文件都包含一个 hooks 文件,你可以在此文件夹根据钩子的名称来创建相应的钩子文件,当 git 执行某些操作时相应的钩子文件就会被执行

    下图中就是各个钩子的案例脚本,可以把 sample 去掉,直接编写 shell 脚本执行:

    347714a0cc6ea15af6ebb33956606227.png
    image.png

    通常情况下我们会使用的钩子有:

    • pre-commit: 执行 git commit 的时候调用,在 commit 提交之前执行,可以检查即将提交代码,如果结果非 0 退出时就会中断此次提交。

    • commit-msg: 由 git commit 或 git merge 调用,以非 0 状态码退出时,会中断此次操作,主要是检测提交的代码注释格式。

    Q:.git 文件下相应的 hook 文件配置可以直接上传到远程仓库,以备其他人拉取达到配置共享的效果吗?

    A:查询了相关资料,在 .git 文件下的 hook 文件配置不能提交到远程仓库,但是可以通过复制配置给其他同事,只是这样并不是我们想要的结果。

    2. husky

    husky 是前端工程化时一个必不可少的工具,由于直接修改 .git/hooks 文件不方便,使用 husky 可以让我们向项目中方便添加 git hooks。

    2.1 pre-commit 库

    项目最开始的时候普遍是通过配置 pre-commit 库起到提交前检测的作用,npm install pre-commit \--save-dev 下载安装之后在项目中按下方配置,当我们在 commit 提交之前就会执行。

    { 
      "scripts": { 
        "lint": "eslint . --fix", 
      }, 
      "pre-commit" : ["lint"], 
    }
    复制代码

    2.2 husky + pre-commit 钩子

    除了只使用 pre-commit 库进行提交前代码检测以外,目前最常用的就是使用 husky,npm install husky \--save-dev 安装之后在 package.json 中 配置,可以搭配使用 pre-commit 钩子,这样当提交 commit 的时候就会执行脚本 npm run lint 进行全项目文件检测。如果只是目前配置的话。

    注意:如果某个项目之前是通过 pre-commit 库进行预检测的话,后面想换成 husky + pre-commit 钩子 的模式检测的话,需要删除 node_modules 之后再 install 才正常生效,因为本地 node_modules 中的 pre-commit 库还在,两者会产生冲突导致执行 husky 失效。

    { 
      "husky": { 
        "hooks": { 
          "pre-commit": "npm run lint", // 在commit之前先执行npm run lint命令 
        } 
      } 
      "scripts": { 
        "lint": "eslint . --ext .js,.vue", 
      } 
    }
    复制代码

    3. lint-staged

    husky 配置已经可以轻松的实现提交前代码检测,但是直接使用检测也会带来了很多弊端,比如每次提交都会检测项目所有文件。如果想要只检测提交过的代码的话我们就可以使用 lint-staged,lint-staged 只读取暂存区的文件、并运行配置好的脚本,避免了对未提交到暂存区的代码造成影响。lint-staged 过滤文件采用 glob 语法,它可以配合 husky 使用,由 husky 触发 lint-staged,再由 lint-staged 执行脚本,配置好之后既可以减少 eslint 全量检测时消耗时间过长的问题、又可以减少修复问题占用的时间!

    // package.json 文件
    
      "husky": {
        "hooks": {
          "pre-commit": "lint-staged",
        }
      },
      "lint-staged": {
        "*.vue": [
          "eslint --cache --fix"
        ],
        "*.js": [
          "eslint --cache --fix"
        ]
      },
    复制代码

    3.1 两份 .eslintrc.js 配置

    有一些项目他不是单独的 vue 项目或 node 项目,类似xx系统有用 node 做中间层,这时候一个项目中就会有两个环境,为了针对不同环境的文件夹下用不同的规则集进行检查,我们这里准备配置两份 .eslintrc 文件,主要配置如下:

    // package.json 文件
    
    "scripts": {
      "lint": "npm run lint-web && npm run lint-node",
      "lint-web": "eslint . -c ./.eslintrc-web.js --ext .js,.vue --ignore-pattern server/ --cache --fix",
      "lint-node": "eslint server/ -c ./.eslintrc-node.js --ext .js --cache --fix",
    }    
    复制代码
    // .eslintrc-web.js 文件
    
    module.exports = {
      root: true,
      plugins: [
        '@zly'
      ],
      extends: [
        'plugin:@zly/vue',
      ],
    }
    复制代码
    // .eslintrc-node.js 文件
    
    module.exports = {
      root: true,
      plugins: [
        '@zly'
      ],
      extends: [
        'plugin:@zly/node',
      ],
    }
    复制代码

    配置完之后运行可以正常抛错 error,但是自动 autofix 的功能全部失效了。后续发现可能是因为我们把 .eslintrc.js 改成了 .eslintrc-node.js、.eslintrc-web.js 导致的问题,更改之后 ide 无法动态识别 eslint 的配置。不过在编辑器中可以手动配置,但是每个人的编译器都要手动配置真的比较麻烦,于是我们就想到了之前的参数 root。

    3.2 root 测试

    前面介绍 root 参数的时候,有对着官方文档及网上看相关的翻译,总觉得好像不同的翻译都不一样,而且我自己单独对这个概念也模棱两可的,所以就做了一个 root 的一个测试实验。主要是项目 eslint-root-test 根目录下新建一个.eslintrc.js文件、在根目录的 server 文件夹下也新建一个.eslintrc.js文件,针对两个.eslintrc.js 中 root 配置不通过的情况进行测试,测试结果如下:

    befac3845c97c3f53d3836c5af0c799d.png
    image.png

    根据以上测试结果发现,root 恰好能解决我们想要两份 rc 的需求,于是针对智能系统在跟目录下设置了 .eslintrc.js 文件,在 server 文件下设置了 .eslintrc.js 文件,两份 rc 文件 root 都设置为 true,最终配置为:

    // package.json 文件
    
      "husky": {
        "hooks": {
          "pre-commit": "lint-staged",
          "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
        }
      },
      "lint-staged": {
        "*.vue": [
          "stylelint --config /.stylelintrc.short.js",
          "stylelint --config /.stylelintrc.js --fix",
          "eslint --cache --fix"
        ],
        "*.css": [
          "stylelint --config /.stylelintrc.short.js",
          "stylelint --config /.stylelintrc.js --fix"
        ],
        "server/**/*.js": [
          "eslint -c ./server/.eslintrc.js --cache --fix"
        ],
        "!(server)/**/*.js": [
          "eslint --cache --fix"
        ]
      },
        
      "scripts": {
        "lint": "npm run lint-web && npm run lint-node",
        "lint-web": "eslint . --ext .js,.vue --ignore-pattern server/ --cache --fix",
        "lint-node": "eslint server/ -c ./server/.eslintrc.js --ext .js --cache --fix",
      },
    复制代码

    执行 npm run lint 可以全量跑所有文件的检测,如果单独检测可以单独执行 npm run lint-web 和 npm run lint-node,lint-staged 中配置也针对 server 文件及非 server 文件进行暂存区文件检测。

    4. package.json 与 node_modules 中依赖版本不同时处理

    check-dependencies库:www.npmjs.com/package/che…[6]

    我们常常会碰到这样的问题,当 pull 拉的最新的代码有个依赖升版了、但 node_modules 本地安装的依赖版本还是旧的时候,这时候运行是没有问题的但是两边依赖能够保持同步一致才是最好的。

    问题一:

    Q:如果需要每次 package.json 中我们自己的私有 npm 包依赖更新了,但是本地还是旧版本,怎么让针对私有 npm 远程和本地版本不一致的问题给出提示呢?

    解决一:

    A:找了一下没有找到特别合适的解决办法。

    解决二:

    A:针对自己发布的包做这种提示的方法没有找到很合适的,但是在寻找的过程中发现了check-dependencies这个库,这个库不会检测某个依赖,它是针对 package.json 中所有的依赖进行远程和本地的比对,但凡有一个不同步就会给出提示。

    4.1 npm script 钩子

    npm script 是记录在 package.json 中的 scripts 字段中的一些自定义脚本,使用自定义脚本,用户可以将一些项目中常用的命令行记录在 package.json 而不需要每次都要敲一遍。npm 脚本中有提供 pre 和 post 两个钩子,自定义的脚本命令也可以加上 pre 和 post 钩子。例如 dev 脚本命令的钩子就是 predev 和 postdev,用户在执行 npm run dev 的时候,会自动按照下面的顺序执行:

    npm run predev && npm run dev && npm run postdev
    复制代码

    4.2 check-dependencies

    下载安装 check-dependencies 之后,于是打算在 predev 钩子中执行 node check.js 脚本,当执行 npm run dev 的时候会预先执行 predev 中的命令,如果发现两边依赖不同时就进行抛错中断,当两边一致之后才能正常运行:

    // package.json 文件
    
    "scripts": {
      "predev": "node check.js"
    }
    复制代码
    const output = require('check-dependencies')
      .sync({
        verbose: true, 
      })
    
    if (output.status === 1) {
      throw new Error('本地依赖与package.json中不同步,请先npm install再执行')
    }
    复制代码
    1fd8886c8497616d143c2b9045ae6c3b.png
    image.png

    由于每个项目需要额外放一个 js 文件这样不是很友好,后面尝试看看能不能直接一个命令执行检测报错就可以,发现 check-dependencies 库本身其实已经支持直接执行报错:

    // package.json 文件
    
    "scripts": {
      "predev": "check-dependencies"
    }
    复制代码
    10bdd0c97749de04b2657522b2e38a1a.png
    image.png

    六. 后续发展

    1. 日常维护

    目前已经替换了大部分项目且测试正常,对新项目接入检测工具只需要安装 npm 包,在 .eslintrc.js 中配置即可生效、简单又方便,后续也只需要针对其中某些规则进行统一就可以了。

    2. 待解决项

    测试过程中其实还是发现了很多问题的,比如刚开始我自己但是比较习惯用 webstrom 的,但是它测试的时候真的问题太多,遵循单一变量原则就使用 vscode来进行测试,其中问题搜了很多地方都没有解决办法,问题主要如下:

    • 同一份配置,vscode 可以正常自动 fix,但是在 webstrom 中 eslint 自动 fix 失效

    • sourcetree 中提交代码的时候会绕过 eslint 检测,原因不详

    3. 本文参考

    命令行工具调试:segmentfault.com/a/119000001…[7]

    ESLint 在中大型团队的应用实践:tech.meituan.com/2019/08/01/…[8]

    关于本文

    作者:跑路砖家

    https://juejin.cn/post/7035614700700368910

    6290552754be963f9431c4537a537b27.png

    往期推荐

    大厂面试官:我理想中的前端

    235f0e0bbee3ec83256b046de98bc3b5.png

    对话Svelte未来,Rust 编译器?构建大型应用?

    4b342469ef8e6a4356b7003c99944f13.png

    收藏!史上最全 Vue 前端代码风格指南

    8348b41252ee7ba968a283613aefc58c.png


    最后

    • 欢迎加我微信,拉你进技术群,长期交流学习...

    • 欢迎关注「前端Q」,认真学前端,做个专业的技术人...

    04e35a305ada230ecc8eaba1d7c12347.png

    e53e811e1e57bd8ed1bac540a6e644d7.png

    点个在看支持我吧

    29de849708ffee001ce795869f5f82e1.gif

    展开全文
  • 代码审查的必要性和最佳实践

    千次阅读 2021-05-20 15:17:56
    目录 代码审查的流程 代码审查的争议 加班要累死了,完成项目都来不及,还做什么代码审查? 代码审查太费时间,改来改去无非是一些格式、注释、命名之类不痛不痒的问题。...代码审查工具 一些 Code Re
  • 前端代码审查和测试

    千次阅读 2019-08-16 17:59:18
    检查代码的概念和过程 https://zhidao.baidu.com/question/499002410583455364.html 1、代码检查法 (1)桌面检查:这是一种传统的检查方法,由程序员检查自己编写的程序。程序员在程序通过编译之后,对源程序代码...
  • 前端开发常用工具

    2022-05-01 23:06:59
    文章目录前端开发常用工具前言一、常用的代码编辑工具二、使用步骤1.引入库2.读入数据总结 前言 提示:这里可以添加本文要记录的大概内容: 我们工作和生活种中都需要借助各种各样的工具,所以工具对我们来讲非常...
  • 前端工程化:vue代码检查工具vetur

    千次阅读 2020-09-17 15:46:58
    vscode插件 格式化代码、高亮、代码格式检测、自带Emment、括号自动补全, 专为vue而生
  • 前端代码检查

    千次阅读 2018-05-12 13:51:32
    程序员必备的代码审查(Code Review)清单 代码检查很重要,原因有三: 避免低级bug:一些常见代码问题,如果在编译或运行前不能及时发现,代码中的语法问题会直接导致编译或运行时错误,影响开发效率和代码质量...
  • 我们在使用网站过程中,经常会遇到慢的问题,为了找到原因,一般需要借助工具进行检测,通过工具,可以检测出前端站点加载资源的相关详细情况。
  • 代码审查的四种方式

    万次阅读 2019-05-07 10:33:16
    下文阐述了4种主流的代码审查(code review)类型,相信作为专业的开发人员,你应该都了解它们! 每个专业的软件开发者都知道,代码审查是任何正式开发过程中的必要环节。但大多数开发者不知道的是,代码审查分为很多...
  • 一、背景本篇介绍的是如何做到在代码提交前,统一团队代码风格,检查代码质量,并修复一些低级错误。最终期待项目中的开发人员提交的代码都符合代码规范、风格统一。二、组合技Git Hook + lint-staged + Prettier + ...
  • 前端开发常用哪些工具软件?

    千次阅读 2022-05-17 17:00:40
    前端开发必备工具,一篇文章一网打尽 文章目录 一、前端提高“生产力”工具 1.WebStorm 2. 远程开发 - VSCode 3. 接口测试 - Postman 4.API在线文档生成和测试 - SwaggerUI 5.抓包工具 - Wireshark 6.通用...
  • 说透代码评审一、为什么要评审1.1 不审查的坏处1.2 评审的好处二、评审的困境和争议三、搞清楚评审形式四、评审对象有哪些五、评审参与人员六、评审应该关注哪些七、评审的流程有哪些八、审查步骤和方法8.1 代码审查...
  • 前端性能优化(六)01-页面性能优化之优化工具——JsPerf代码性能对比工具 & moment().format()-时间组件 代码优化——写出优质的代码 命题很大,但是我们要简化来谈一下。...代码审查 单元测试 异常与错误机制
  • 简介:5 款阿里常用代码检测工具免费体验,仅需 2 步,Cherry键盘、公仔抱回家,100%拿奖!作者 | 喻阳面临问题在日常研发过程中,我们通常面临的代码资产问题主要分为两大类:代码质量问题和代码安全漏洞。1、代码...
  • 代码审查是软件开发中常用的手段,安全性和代码质量对于构建高质量软件至关重要。今天,小编就来为大家介绍11个实用的代码质量审核和管理工具,希望对你有所帮助。 1、SonarQube SonarQube在市场上很受欢迎,它...
  • eslint: 是一个开源的、可配置、可扩展的JavaScript代码审查工具 - 代码的规范 + 所有行尾不加分号 + 文件结尾有且只有一个空白行 + 对象属性后的冒号,后面有空格,前面没有 + 属性值必须是单引号,不可以是双引号...
  • Jenkins骚操作第七章sonarqube代码审查

    千次阅读 2022-02-18 08:33:14
    目前支持java,C#,C/C++,Python,PL/SQL,Cobol,JavaScrip,Groovy等二十几种编程语言的代码质量管理与检 测,底层使用elasticsearch作为代码检索工具 官网:https://www.sonarqube.org/ | 软件 服务器 版本 jdk...
  • docker运行gerrit(代码审查工具)

    千次阅读 2020-02-09 13:44:47
    Gerrit,一种免费、开放源代码的代码审查软件,使用网页界面。 gerrit背景 Gerrit,一种免费、开放源代码的代码审查软件,使用网页界面。利用网页浏览器,同一个团队的软件程序员,可以相互审阅彼此修改后的程序代码...
  • 基于 Git 的 CMS:使用 Git 进行用户管理、访问控制、内容审查前端:(这个回购) Gatsby.js、React.js、TailwindCSS 了解有关更多信息 如何构建 确保您的计算机上安装了以下工具 安装 Gatsby CLI npm ...
  • 前端 web 开发是一个令人兴奋的领域,越来越多的需求,形成了一个高薪的职业。同时,Web 领域还有很多可靠的工作,使得 Web 开发者能够更加高效的工作。 下面是我在日常开发中经常用到的 12 个工具,分享给大家,...
  • 代码审查

    2019-09-14 20:58:23
    代码审查1.Code Review好处1.1团队知识共享1.2代码质量1.3团队规范2.如何代码审查2.1把Code Review作为开发流程的必选项而不是可选项3.把Code Review变成一种开发文化而不仅仅是一种制度4.Code Review经验技巧4.1选...
  • 如何做前端Code Review

    2021-12-07 14:03:35
    向互联网大厂学习,从代码格式、代码错误、代码习惯、代码优化四个角度进行前端Code Review的具体细则实施。 一、代码格式 代码格式问题可以通过自动化工具来解决。 VSCode格式化设置 标准的 eslint 规则( 如...
  • Jenkins+SonarQube代码审查安装SonarQube安装MySQL安装SonarQube实现代码审查环境配置在项目添加SonaQube代码审查(非流水线项目)在项目添加SonaQube代码审查(流水线项目) SonarQube是一个用于管理代码质量的...
  • 前端调试工具详解(一)

    万次阅读 多人点赞 2018-07-10 19:01:04
    原文点击打开链接常用的调试工具有Chrome浏览器的调试工具,火狐浏览器的Firebug插件调试工具,IE的开发人员工具等。它们的功能与使用方法大致相似。Chrome浏览器简洁快速,功能强大这里主要介绍Chrome浏览器的调试...
  • 代码审查思考

    2022-03-10 14:25:10
    代码审查思考

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,627
精华内容 3,050
关键字:

前端代码审查工具

友情链接: XS128.zip