Code Health Devlog 1 - Idea and Extension Setup

Devlog Purpose

The primary purpose of a devlog is to document the development process of a piece of software. During my time at Easy Agile, we regularly hosted mini-hackathons. They were fun because we got to collaborate with different people, and see all the cool ideas at the end of the event. However, I never had any ideas for the themes of them.

I finally had an idea that could be useful for me though. I thought, why not create a devlog that I can share the journey with readers. It should double as something to keep me occupied, and motivated during the uncertain times in the software industry.

Problem

Throughout my career I have had to deal with technical debt. From removing lodash, other large refactors, to avoiding the debt all together due to a lack of capacity or priority. Over time, avoiding this work degrades the maintainability of a codebase, slows down development, and can cause bugs or vulnerabilities.

There are strategies to keep on top of a codebase's health, such as lint rules, encouraging a refactoring culture, and defining coding standards, etc.

However, these strategies don't give me visibility that I'm satisfied with. It easily becomes out of sight, out of mind. Also, some lint rules are not always feasible to turn on in brownfield projects because it could require a large refactor that isn’t prioritised.

Solution

This brought me to the idea of Code Health. A VSCode extension that provides a report of the health by way of code smells. The main goal of the tool is visibility of the code's health, thus encouraging engineers to leave the campground cleaner than they found it.

I believe this visibility is valuable, especially during an era where code can be generated at such a rapid pace with AI tooling. Keeping a project's health in shape with clear, consistent patterns and reduced smells has many benefits. Increased development speed, developer satisfaction, and reduced chances of an LLM's output being unsatisfactory.

Getting Started

First, I began by researching and reflecting on common code smells. This is the initial list I came up with to execute on.

Second, I paired with Claude to get a VSCode extension template started. (I’d never created an extension before.) The pairing session allowed me to gain an understanding of VSCode extension development. Some questions I asked,

Third, to get an idea of what it could look like, I sketched a wireframe in tldraw.

At this point, I’d got a repository setup, understanding of extension capabilities and UX guidelines, and an idea of what it could look like. Now, I need to establish the codebase structure and patterns to get Claude generating logic in a way I’m satisfied with. The patterns I’ve seen the most success with lately is,

I asked Claude to generate the dead code logic and internal bundle size detection, provided it with snippets of the wireframe, then established the patterns mentioned. At this point iterations for the loading, error, and additional smells sped up. The LLM output regularly follows the patterns I established giving me more confidence in the output.

Here is a short demo running the extension against the repository for my website.

Roadmap