The blog post I decided to talk about is on “Design Smells” in software development. I chose this topic because we’ve touched on it in class during assignments where we matched the correct design smell to its definition. It’s an important concept to understand since we’ll be working with API designs and need to know how to avoid these issues. In the post written by Keith Casey, he compares design smells to your car sounding weird or your “Spidey Senses” going off, subtle signs that something is off with your code or design. He focuses on four main design smells: Inconsistent naming, CRUD-only APIs, Customer-specific features, and Per-resource versioning.
He gives a realistic example of inconsistent naming with variables like interest_rate, intRate, and iRate. It might seem like a small problem, but those tiny differences can cause major confusion (Opacity). While it may look like just a style issue, it often shows that team members have different understandings of the same concept. I’ve seen this happen in class, where one student uses userName and another uses username. It makes the code harder to read and maintain. In the future, I think it’s important for teams or individuals to agree on consistent variable names early, so the code stays clean and easy to follow.
The next design smell discussed is “CRUD over HTTP”. I wasn’t too familiar with this one, so it was interesting to read about. This happens when an API just wraps a database without adding any real logic (Needless Complexity), which the author calls a “glorified database.” Using methods like GET, POST, PUT, and DELETE might seem correct, but if your API only moves data around, it’s not doing much. A good API should validate input, include logic, and make the system useful beyond basic storage. We’ve talked about these HTTP methods in class, learning how each one interacts with data, so this gave me new ideas. Before, I only thought about what each method did; now I’ll think more about what the API is modeling and how it supports the system’s purpose.
For the last two design smells, customer-specific functionality and per-resource versioning, both show how small design changes can turn into big headaches. Customer specific functionality happens when a team adds a feature to please one customer. It sounds harmless, but every tweak adds complexity, more testing, and a higher chance for things to break. The author makes a good point to inspect each request carefully and compare it with the API’s design. The last design smell gives each resource its own version number. It may sound flexible, but it quickly becomes messy and confusing for users. These two examples show that good design means knowing when to say no and keeping things simple within the API.
Overall, this blog post helped me understand how small details can affect the bigger picture in software design. “Design smells” can be avoided with a little attention and ensuring not adding things than can be needlessly complex.
Source: https://caseysoftware.com/blog/api-design-smells
From the blog CS@Worcester – Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.