I decided to read Pavan Kumar S’s blog, “Refactoring 101: Code Smells – Bloaters.” This post explains a specific code smell called “bloaters,” which starts when parts of your code grow too large and become difficult to maintain. The topic of this blog connects to our course work and topics on design principles, going over code smells and refactoring just like we’ve done in our lectures and homework.

Pavan Kumar describes bloaters as a sign that a program has become overcomplicated and cluttered. He picks out examples such as long methods, large classes, and long parameter lists. Each of these examples show a situation where code tries to handle too many responsibilities at once, causing poor readability and maintainability. Kumar suggests several refactoring techniques to combat these problems, including Extract Method, Extract Class, and Introduce Parameter Object. These techniques can be used to simplify your code by breaking large structures into smaller, specialized units. The blog explains that the goal of refactoring is not to change the external behavior or output of the program but to improve its internal structure so that it remains easier to understand, test, and extend in the future.

This blog appealed to me because it provides a clear explanation of a problem I often run into in my own programming projects. When writing assignments or personal code, I tend to write long methods that handle multiple tasks without modularity or specialized methods in mind. I’m aware of this bad habit because I mostly do it as I usually work with smaller projects that don’t require too much. Although it works initially, the code quickly becomes messy and difficult to modify or expand. Reading this blog was helpful for me since I recognized I recognized my bad habit when writing code.

What stood out most to me was how important refactoring can be in design principles. This was showcased in the duck homework where we have to refactor bad code. This only reinforced the idea and helped me better digest that concept of refactoring. A bloated method or class commonly goes against these ideas by combining too many responsibilities in one place. If you refactor and divide functionality into smaller pieces, each part of the code is more manageable and much cleaner. This short concept reinforced the idea that refactoring is not simply about cleaning up code, it’s good design habit.

From this reading, I picked up on the idea that refactoring does not have to be a massive rewrite or a stressful task. Small improvements like breaking large classes into manageable ones can prevent the slow build up that often happens in growing projects. Hopefully, I can incorporate regularly reviewing my code for signs of bloat and make refactoring part of my skillset.

https://medium.com/testvagrant/refactoring-101-code-smells-bloaters-f80984859340

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

When I first started learning about REST APIs, I thought it was just about how apps talk to each other over the internet. But after reading the REST API Tutorial, I realized that REST is much more than just sending HTTP requests. It’s an entire way of thinking about how systems communicate efficiently and reliably. … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

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.

So for this second quarter’s professional development activity, i read the Stack Overflow post, “Best practices for REST API design”(https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/), in basics it covers the fundamental guidelines for designing Restful APIs that are both efficient and developer-friendly, covering some key principles like properly structuring URLs, making sure to use nouns instead of verbs when it comes to endpoint naming, implementing HTTP methods accordingly to standards as well as ensuring consistency in API design. The post also talks a little bit about versioning, error handling and security as vital aspects of any production-level API.

I selected this specific resource considering it does relate to what we were doing in class and some of our homework as well, since we’re getting involved on building maintainable, modular systems and REST APIs are just one of the common interfaces used in modern software architecture, for anyone trying to work in backend development you can deepen your understanding of how to design APIs that other developers can easily understand, use and extend to some degree.

From the rest of the article(no pun intended), I learned that REST isn’t just about making the things in question work but having a consistent and predictable interface that makes client-server communication easier. I like how the article broke down best practices for naming conventions, like how using resource-based URIs like /users or /orders/1234 instead of action-based ones like /getUser makes the API more intuitive. I also remembered about the significance of using HTTP status codes, like 201 Created for successful POST requests or 404 Not Found for missing resources. These small details can contribute somewhat to API usability and maintainability.

So i’d say pretty much that the article reinforces the more architectural concepts that we’ve discussed before in class, like abstraction, modularity and encapsulation. An API that is well-designed abstracts away complex backend logic and presents a clean, understandable interface much like how we design modules in general when it comes to software construction. I also like to think that it connects to our work when it comes to some other software design principles like separation of concerns and loose coupling. RESTful Design makes it so that different parts of a system can evolve independently, which is essential for large-scale software projects.

If i had to reflect on this after my reading of the article, i would say that i realize on some occasions i find myself taking shortcuts when designing endpoints for personal projects, mostly just trying to focus on making sure it’s functionality is in suitable position as opposed to focusing on structure, but after my reading i think i’ll try to be more deliberate when it comes to naming conventions, HTTP method uses and documentation.

Overall, this resource gave me a clearer framework for thinking about web service design, and I can already see how it will help me create more scalable and maintainable software in future projects.

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.