Pareto’s 80/20 Rule and preventing errors in Frontend Development for a better quality
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
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 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.
Priority Two (Development)
The code does not create itself (yet), humans do!
Take your time: Before directly jumping on writing the code, sometimes it’s best to take a step back and think about how you would implement something. Sitting down and thinking through the business need, requirements and implementation will save you a lot of time in the future.
Clean code practice:
Write a code that sings.
Write clean and shortcode blocks. Wrapping things into smaller code blocks allows you to make more meaningful names. It is very difficult to figure out the defect when you have massive methods and classes. It can be very difficult to figure out what the original logic was. Variable, method and class names are vital to understanding code. I would highly recommend reading Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
Unit Testing:
Do not negotiate with Unit testing; it’s not an optional thing. Test-driven development should be strictly followed. If you follow the two points mentioned above, it would be very easy to write a testable code.
Read more about UI Testing by @NoriSt ehttps://anoop-gupt.github.io/ui-testing-best-practices/
Security and Performance testing: Post-deployment security and performance testing are mandatory. These two tests should be done on a deployed application as a part of your CI/CD pipeline. Tools like OWASP, ZedProxy, Snyk, Sitespeed and PageSpeed are highly recommended.
Automate Your Testing, Catch Bugs Early:
As the system gets larger, developers spend more time fixing bugs. Eventually, it gets to the point where the developer is not productive at all. Getting out of this situation is a huge challenge and many developers simply opt to constantly fix bugs.
Automated testing allows developers to catch many bugs as soon as they happen. It’s not perfect and you should still test the traditional way, but it can go really a long way.
Look at the Testing Pyramid below for a better test automation strategy:
Bonus Tip:
Load testing during development through K6 . k6 is a modern load-testing tool, building on Load Impact’s years of experience in the load and performance testing industry. It provides a clean, approachable scripting API, local and cloud execution, flexible configuration, with command and control through CLI or a REST API.
Priority Three (Post Development)
Continuous Refactoring:
No one is perfect and writes a perfect code at first. Never settle with your code and keep improving it. Take the time to go back and clean the code up while it’s still fresh in your mind. Rename variables, add meaningful comments, and break apart tightly coupled code into small units which eventually helps in writing unit tests. The quality of the code will greatly improve and you will thank yourself two months down the road when changes need to be made. Continuous code refactors will create the best code.
Boy Scout Rule:
THE BOY SCOUTS HAVE A RULE: “Always leave the campground cleaner than you found it.” If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers. It should be each developer’s responsibility to provide maintainability and cleanliness of the code whether it belongs to him/her or somebody else.
Automating Releases:
There is a very good NPM module semantic-release that automates the whole package release workflow including determining the next version number, generating the release notes and publishing the package. This removes the immediate connection between human emotions and version numbers.
It is meant to be executed on the CI environment after every successful build on the release branch.
Documentation:
The presence of documentation helps keep track of all aspects of an application and it improves the quality of a software product. Its main focus areas are development, maintenance and knowledge transfer to other developers.
“Document This” is a Visual Studio Code extension that automatically generates detailed JSDoc comments for both TypeScript and JavaScript files.
Production bug tracking and reporting:
There should be a system in place to log the real-time bugs that happened in the end-users environment. It will help the development team to complete steps to reproduce the bug and analyze the expected behaviour vs observed behaviour.
LogRocket is a good open-source tool. It lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. Be mindful, some advanced features are paid though.
App Dynamics is another tool to record the session of the end-user during User Acceptance testing.
Conclusion:
Thanks to the ever-changing web technologies, a large number of new tools are launched constantly. The above list contains some of the best Front-end development tools and best practices which, if rightly implemented, will ensure the production of quality products.
The takeaways of this blog:
- Automate everything
- Learn and customize your tools through progressive tooling
- Keep documenting your lessons learned
- Continuous refactoring and testing
- And finally, don’t ignore the 80%
