What is Pareto’s rule?

The Pareto principle states that for many events, roughly 80% of the effects come from 20% of the causes. Source Wikipedia

The 80/20 rule, the law of the vital few, or the principle of factor sparsity

80/20 rule can be applied in various areas, but particularly, if we talk about software development, it has been observed that “20 percent of the code has 80 percent of the errors. Find them, fix them!”

For example, Microsoft noted that by fixing the top 20% of the most reported bugs, 80% of the related errors and crashes in a given system would be eliminated.

Why is it important for (Frontend) Development?

In Frontend development, one of the biggest challenges is to cope up with the vast landscape of browsers, frameworks, styling, scripting, accessibility, performance, semantics, and search engine optimization. Continuous changes happening in the Frontend world are making things easier, like rapid development and quick deployments. But any single error or defect will land on a failed product. Thus, every aspect of the Frontend is equally important to produce a quality application or website.

If we talk about catching errors or defects early in our software development lifecycle, we can wind up in a good spot. We can improve our code quality by adding strictness through modern tooling workflow, and apply best practices to avoid commonly occurring errors in order to achieve consistent quality and a good product.

What are the priorities to prevent errors?

By going with Pareto’s principle, we can look at 20% of errors or defects which can be detected and rectified early with the right set of best practices with an engineering mindset and modern tooling applied. A mindset change is required from the beginning of any project.

Here are some quality control priorities we can follow to produce quality code, quality product and a good environment in different phases of development.

These priorities can be picked up in continuous integration also during the build and test phase.

Priority One (Pre-development):

Do not wait; the time will never be ‘just right.’ Start where you stand, and work with whatever tools you may have at your command, and better tools will be found as you go along. By George Herbert

Customize your tools and environment based on your needs

Before going for development, we should create a defense system on the development environment and with the help of right modern tooling, 50% to 60% of errors can be flagged and rectified. It is a must-have (yet not a silver bullet) list of right kind of tooling which every project needs to implement; it can be both further and better integrated.

Linting

To flag various kinds of code style errors, programming errors and some suspicious construct in the code. The Frontend team writes code for various layers of an application in different languages like HTML, JavaScript, CSS, different JS frameworks. Hence we need Linters for every language we use. Here is a list of linters, which can be integrated in our day-to-day development workflow:

HTMLHint — A Static Code Analysis Tool for HTML and rules are customizable.

CSS Lint: If you want to catch errors and enforce convention in your style, configure Stylelint in your workflow. It has 170 built-in rules to catch errors, apply limits and enforce stylistic conventions.

SASS Lint: stylelint-scss is a plugin for stylelint, so it’s meant to be used with it. stylelint by itself supports SCSS syntax very well.

ESLint is an open-source linting tool for JSX and JavaScript web applications. It helps to discover doubtful patterns or find a code that doesn’t comply with specific style guidelines. It allows developers to detect errors in the JS code without executing it, thus saving time. Being written in Node.js, it offers a prompt runtime environment and smooth installation through NPM.

JSHint is a flexible community-driven tool to discover errors and potential issues in your JS code. The main goal of this static code analysis tool is to help JavaScript engineers with complex programs. It can detect syntax errors, implicit data type conversion or leaking variable, though it can’t define whether your software is fast, correct, or includes some memory leaks. JSHint is the fork of JSLint.

Flow is a static code checker for React developed by Facebook. To inspect the source for errors, it uses static type annotations. In fact, types are the parameters set by developers and Flow makes sure that your software meets the requirements.

TSLint is a de facto standard linter for TypeScript language. It is an extensible static analysis tool that checks code for readability, maintainability and functionality errors, supported by Microsoft. You can find a set of TSLint rules used on some Microsoft projects.

Code Formatter

Prettier can be run in your editor on-save, in a pre-commit hook, or in CI environments to ensure your codebase has a consistent style without devs ever having to post a nit-picky comment on a code review ever again!

Misc Linters

editorconfig-cli is a Go-based editorconfig linter.

dotenv-linter finds errors and stylistic violations in .env files.

aspelllint provides spell checking for large projects.

yamllint — Checks YAML files for syntax validity, key repetition and cosmetic problems such as lines length, trailing spaces, and indentation.

markdownlint — Node.js -based style checker and lint tool for Markdown/CommonMark files.

Git Hooks:

Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these Git hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits. You can use these hooks for all sorts of reasons.

Husky: If you don’t want to write hook scripts from the scratch, Husky is the simplest way to have Git hooks in your JavaScript project. Husky can prevent bad git commit, git push and more.

Automation:

This part is very important in order to automate conventional commits, automatic bundle size analyzer.

Commitzen: If you want to provide an easy set of rules for creating an explicit commit history, a convention needs to be enforced. Commitizen can be used to validate your message against the set convention.

Import Cost: This extension will display inline in the editor the size of the imported package. The extension utilizes webpack with babili-webpack-plugin in order to detect the imported size.

Use Traditional Tools:

There are very good browser extensions, plugins which are part of Traditional Tooling and we should set them up before development. These tools can deduct errors from accessibility and performance standpoint.

Accessibility

Totally : is an accessibility (a11y) visualization toolkit and very easy to use to catch on the fly accessibility errors.

Pa11y is your automated accessibility testing pal http://pa11y.org/

eslint-plugin-jsx-a11y by Ethan Cohen. Static AST checker for a11y rules on JSX elements.

react-a11y by ReactJs. Warns about potential accessibility issues with your React elements.

Performance optimization

Lighthouse: An open-source auditing tool that you can use to test and improve your webpage.

Sitespeed.io is a complete web performance tool that helps you measure the performance of your website. It would test websites using real browsers, simulating real users’ connectivity and collect important user-centric metrics like Speed Index and First Visual Render.

Developer Tools: All the browsers come with integrated developer tools. You should have a good command over them.

An important Module:

Liblice: liblice is a module to detect licenses throughout your entire installed dependency tree.