Link: https://blog.codinghorror.com/code-smells/

In the blog post “Code Smells” by Jeff Atwood, he proposes an argument that it is very important for programmers to develop a “code nose,” which essentially is the ability to sense when code is beginning to rot before those bugs even appear. Atwood goes through a long list of common smells within classes, such as long parameter lists, duplicated code, overly long methods, and giant classes that simply try to handle too many responsibilities. He also describes smells that are between classes. This includes primitive obsession, where basic types are being overused instead of proper classes, as well as data classes that only store fields but have no behaviors. He also describes feature envy, which is when one class is constantly reaching into another class’s data. His main point is that while refactoring tools and books is helpful, the real key is to learn how to notice these warning signs in your own code.

I chose this topic because I feel like I didn’t get a great understanding of code smells in class, so I felt like it would be beneficial to get a better understanding of it. This blog post was very resourceful, as it reminded me that readable and maintainable code is just as important as whether or not the code is functionable. Sometimes, I get too focused on making sure that the code just works but I don’t pay attention to the readability or maintainability aspect of it. Reading about code smells made me realize that some of these habits apply to my own work. I have definitely been guilty of data clumps before, as sometimes I pass the same group of variables through multiple functions rather than bundling them together into a class. I’ve also definitely done the long method smell before too, as sometimes I keep lumping stuff into main() rather than creating helper functions which makes it more readable and easier to maintain.

Going forward, I plan to use this list of code smells as more of a mental checklist whenever I am working on a group project or assignment. This will improve my own code by making it more readable and maintainable, but will also prove to be beneficial in a workplace environment. In my career, this will help me navigate potentially unfamiliar code bases, and will even help me leave code cleaner for my coworkers. Overall, understanding code smells will prove to be beneficial for myself as well as my potential future coworkers.

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

I have never worked on front end development until now. My preconceived notions made me think this would be simpler like web design, but I was wrong. This is the piece that the users interact with directly. Mistakes here make the project look sloppy, reduce user satisfaction, or can make it hard to navigate. The front end is the first impression, if this leaves a bad taste, then it may lower user satisfaction.

Front end development relies on three things, html, css, and javascript. HTTPs give us the skeleton of the page. It shows where our elements like headers, images, and links go. CSS takes what we have and stylizes it. This handles things like colors and layers. This is also responsible for ensuring the front end looks good on whatever device it is ran on. And finally java script introduces dynamic behaviors. This can include dropdown menus, data fetching, animations. This pulls everything together to create a responsive UI.

There’s a lot of good front end tools to check out. Tailwind css allows you to simply learn styling patterns that work, without having to write full css files. Bootstrap is a css framework that provides pre-built ,https, javascript and css components. Apparently 19% of all websites were created with this. Css loaders give you hundreds of loading animations that you can use in your projects. Coolers are a pallet generator. This allows you to see a variety of color pallets to choose from so you can see what you link and implement into your front end. A lot of these tools seem very interesting and have gotten me more interested because they seem very simple to implement while making your project look cleaner. These tools don’t exist to replace doin the work yourself. These are in place to support the core aspects of front end development. Some of these tools will help you build a layout faster, and other tools like codepen allow you to test without having a complete project. They give the developer some simple quality of life improvements that can make the process more streamlined.

https://www.wearedevelopers.com/en/magazine/210/best-tools-for-front-end-development

https://martijnhols.nl/blog/accessibility-essentials-every-front-end-developer-should-know?

From the blog CS@Worcester – Aaron Nanos Software Blog by Aaron Nano and used with permission of the author. All other rights reserved by the author.

In building software, it’s easy to focus on writing code, making features, and getting things working. But real, maintainable systems require more, they require thoughtful architecture. In the article “Five Architectural Principles” posted in the Criteo Engineering blog on Medium, Peter Milne lays out five foundational principles that, in his experience, guide sustainable and scalable software systems. The article is short but it outlines an architectural mindset that feels especially relevant.

Milne begins by outlining five principles he believes lead to more maintainable systems, grounding each one in how teams can better structure software over time. He doesn’t claim that implementation is unimportant, but he does consistently direct attention towards fundamental architectural choices. That emphasis made me reflect on how many of my past projects became unmanageable messes simply because I was focused on writing code rather than the structure supporting it.

One of the principles that Milne discuss is the important of designing components around well-defined responsibilities. He explains that keeping components focused on a single purpose helps reduce unnecessary complexity as systems evolve. His explanation made the idea more concrete for me, especially because it aligns with some of what we’ve learned in class about separation of concerns and the value of components that can change independently.

Milne also emphasizes the importance of clear contacts, the rules or interfaces that describe how parts of a system should interface. He presents contracts as a way to maintain stability, even when internal implementation details change. His explanation made me think about much smoother some of my past group projects would have been if interfaces had been clearly defined from the beginning.

Milne also makes it clear that architectural decisions should be intentional rather than accidental. He doesn’t prescribe strict formulas, but he encourages thoughtful design so that systems can evolve without becoming overly complicated. That perspective resonated pretty heavily with me because it connected to an overarching theme that’s been prevalent throughout 343: the choices we make early on influence how well a system can adapt in the future.

Reading this helped me rethink the way I want to approach future projects. Instead of immediately writing code, I want to start by defining boundaries, identifying responsibilities, and agreeing on interfaces. Architecture is meant to support the system, not struggle to keep up with it. Even though Milne’s article is fairly brief and pretty corporate, it made me realize the value of the invisible structure supporting the visible behavior of software.

https://medium.com/criteo-engineering/five-architectural-principles-d32dc2bfefae

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.

For this blog I chose to explore the article “REST API Design: Architectural Foundations and Modern Practices” by Nikola Lazarov. Since CS-343 focuses on software construction, modularity, and clean interfacing, I wanted to learn more about how REST APIs fit into architecture beyond the basic GET/PUT/POST/PATCH commands. Lararov’s article stood out because it connects the roots of REST with other practical API design conventions we’ve learned in 343.

Lazarov begins by grounding the discussion in the original REST constraints defined by Roy Fielding. These include ideas such as statelessness, a uniform interface, resource-based design, and layered system architecture. The article then explains how these constraints influenced real world API design today. He connects these constraints directly to the goals of scalability, simplicity, and clear separation of concerns. For example, the statelessness requirements means that each request must contain all the information the server needs, which helps a system scale because servers don’t need client-specific context. His explanation in the article helped me understand that REST is a set of architectural decisions that influence how the entire system behaves and it isn’t nearly as independent as I thought.

The article also discusses how to apply REST principles in API design. Lazarov highlights the importance of resource-oriented URLs and matching HTTP methods, GET for retrieving, POST for creating, PUT for updating, and DELETE for … deleting. He also greatly emphasizes using meaningful HTTP status codes to communicate consistently. These design choices might seem small, but that’s kind of the entire point, these choices contribute to APIs that are predictable and easier for clients and developers to understand. Rather than presenting REST as a rigid formula, Lazarov explains how these principles guide the structure of modern APIs, helping developers create interfaces that are both intuitive and aligned with broader architectural goals.

I selected this article because I believe that it directly ties into topics we’ve explored in 343. REST APIs are essentially interfaces between components of service, so understanding why they are designed the way they are is directly relevant. I also wanted a source that explains the “why” behind REST’s patterns instead of just the “how.”

What I learned most from this article is how intentional REST API design is and what it should look like. I had previously thought of endpoints of pretty arbitrary choices, but Lazarov’s explanation helped me understand that each part of an API should reflect the underlying REST principles.

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.