7 Deadly Sins: Chapter 1 — Standardization in React
At the heart of Beaver Dam, a team of developer beavers were hard at work building Wisedoc, an AI-driven resume builder. Among them was Barry, an experienced developer who would soon face a common but underappreciated challenge in software development.
The Sin: Ignoring Standardization in a Collaborative React Project
As the team dove into their React development, a subtle issue surfaced: the lack of code standardization. This seemingly innocent oversight started causing real headaches, turning their React codebase into a hotpot of varying coding styles and conventions.
War 1:- The Heterogeneous Codebase: Each developer had a unique way of writing code. Barry favored functional components and hooks, while Betty preferred class components. The resulting codebase was a tangled mess, with everyone’s individual coding styles interwoven without any clear structure.
This lack of standardization had far-reaching consequences. Debugging became a daunting task, reading a teammate’s code felt like deciphering a foreign language, and resolving merge conflicts became a frequent and time-consuming chore.
The Redemption: Implementing Standardization
Barry, recognizing the escalating issue, decided to champion code standardization. The objective was to unify their coding styles, conventions, and practices, to shape a more coherent and maintainable React codebase.
Barry addressed the issue of inconsistent use of React features head-on. After a team discussion, they agreed to use functional components and hooks consistently, putting aside class components. This decision was made based on the benefits of functional components and hooks, such as easier testing and better reusability as shown below:
War 2:- Consistent Syntax Styling
Barry and Betty are two enthusiastic developers but they overlooked a crucial aspect. For the same logic, their approaches were dramatically different. Here’s how they each wrote a function to calculate the total experience from an array of jobs
Realising it, they introduced ESLint and Prettier into their workflow to enforce consistent syntax and coding styles. They used ESLint to help spot and fix potential issues in their code and Prettier for automatic code formatting. Here’s a glimpse of their ESLint and Prettier configuration:
With these in place, Betty and Barry’s function started to look the same, and the previously divergent code styles converged to one:
These standardization efforts began to bear fruit. Debugging no longer felt like a wild goose chase, understanding each other’s code became straightforward, and merge conflicts were fewer and far between. The team could now focus more on developing exciting new features for Wisedoc.
By addressing the first deadly sin of ignoring standardization, Barry and his team are now set for smoother collaboration. But as with any development project, more challenges lie ahead. Stay tuned to find out how they tackle the next JavaScript sin — SOLID Principles
