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.

In our class, in our latest POGIL we’ve started to explore debugging, an essential skill that uses different tests, tools, and commands.. The blog post “Supercharge Your Debugging with Git Bisect” by Phil Haack is a blog that talks about debugging with a tool that we’ve just started to familiarize ourselves with. That being git bisect, a command that helps developers locate the specific commit where a bug first appears. I chose this post because I was curious about how this tool can change debugging for me as a developer, as well as the idea of pinpointing where a bug starts in version control.

The post opens with a relatable story about the author facing a bug that had crept into his project over time. Instead of resorting to endlessly going through each commit and running tests, he turned to git bisect to efficiently find the problem. Haack explains how the command works like a binary search. It starts by marking a known commit where the bug exists and a known commit where the program worked correctly. Git then checks out a commit halfway between those two points. After testing that commit, the developer marks it as good or bad, and Git automatically cuts the range of possible culprits down until it pinpoints the exact commit where the issue began. Haack further elaborates on advanced features such as skipping commits that can’t be tested and automating the process with scripts through git bisect run. He also notes potential complications, like when the first bad commit is a merge rather than a single code change, which can make debugging a bit more complicated.

I chose this article because debugging is one my worst and most frustrating aspects of coding, and git bisect offers an easier approach that turns guessing into a faster, more efficient search. While I’ve used Git regularly for version control, I only recently realized it could actively help in finding bugs. The examples given in the blog made it easy to understand how bisecting commits can save on time, especially in large projects with long histories.

Reading this blog gave me new ideas about debugging. I’ve always viewed Git as a way to manage versions, especially when working with others, but now I see it as a debugging tool as well. The concept of using binary search to isolate problems makes me think about what other commands can be used to enhance my time when coding. It’s also a heads up that effective debugging depends on maintaining small, manageable commits because without manageable commits, even Git Bisect can struggle to pinpoint a specific change. Hopefully I can incorporate this tool into my workflow whenever I encounter bugs that I can’t find.

https://haacked.com/archive/2024/11/11/git-bisect/

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.

This blog is based on “OOP Principles: What is Object Oriented Programming?” from Full Stack Foundations. The article has a clear understanding of the four core pillars of object-oriented programming. That being encapsulation, abstraction, inheritance, and polymorphism. It also explores how these principles tie into more advanced design ideas such as composition over inheritance and more.

The article begins by explaining why OOP is valuable, emphasizing that it organizes code into modular blocks that bundle together data. OOP helps developers manage complexity in large systems. It then talks about encapsulation as the practice of hiding code and exposing only interfaces, which helps reduce unintended interactions. Abstraction is explained as representing concepts with simplified models. Inheritance is presented as a practice that allows new classes to build upon existing ones, enabling reuse of behavior. Finally, polymorphism is described as the ability to treat different classes as instances of a common base type, making systems more flexible and adaptable. Later in the article, the author connects these principles to design patterns, noting that good object design avoids fragile hierarchies.

I chose this article because it’s connection to our class, discussing design concepts. OOP is a key topic in this course, from abstraction and encapsulation to design principles and patterns, and I thought this blog was a good representation of OOP. It struck a good balance between the basics of OOP and the many ideas that are needed to think about design in a professional way.

Reading this article reminded me that OOP is more than just syntax like classes and methods. The discussion on abstraction and encapsulation stood out the most to me because in my past projects and classes I often never thought about the exposure of too many details of a class, either through public fields or otherwise. The article emphasized that clean abstraction is essential for maintainability. I also appreciated the warning about inheritance. The article shared the idea that using composition over inheritance can prevent problems and lead to more flexible ideas.

The main takeaway for me is that OOP is an idea that allows code to be built clean and modular rather than something that has to be perfected up front. In future assignments and projects, I want to be more aware about the principles of clean OOP coding. I also plan to make better use of interfaces and encapsulation so that classes depend less on concrete implementations. This resource gave me a refresher on these ideas and hopefully I can build systems that are easier to maintain and improve upon.

https://www.fullstackfoundations.com/blog/oop-principles?

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.