I chose the website Refactoring.Guru as my resource for this quarter’s blog post. This site offers an in-depth collection of material covering code refactoring and various software design patterns. The resource directly relates to course material in my Software Construction, Design, and Architecture class, as we recently completed an assignment that involved both refactoring and implementing three specific design patterns: Strategy, Singleton, and Simple Factory. I wanted to deepen my understanding of these concepts beyond the implementation done in my assignment.

Refactoring.Guru provides comprehensive guides on two core concepts in software development: Refactoring and Design Patterns.

Refactoring is the process of restructuring existing code without changing its external behavior, to improve readability and reduce complexity. This site thoroughly explains that refactoring is essential for resolving consequences of prioritizing speed over clean code, aka technical debt; and describes the various types of code smells and techniques for reducing them.

Design Patterns are reusable solutions to common problems found in software design. These patterns are sorted into three categories: Creational, Structural, and Behavioral; the website provides clear descriptions and examples of each type of pattern that falls into these three categories, including the Strategy, Singleton, and Simple Factory.

I chose this resource because I was amazed at the clear and concrete information it provided, and I felt the need for a more comprehensive foundation on these patterns outside of the practice the class assignment gave. I particularly enjoyed using the Singleton Pattern as it clearly visualized being the optimal choice for creating methods that respond to one instance class. Similarly, the Strategy Pattern was a great start in understanding how to refactor code by adding, swapping, and removing parts without needing to rewrite the entire program. This resource offers clear and visual explanations that help bridge the gap between how to implement a pattern and why it is the chosen solution in certain contexts. 

This website has, without a doubt, helped me better understand the reasons behind refactoring and the several types of design patterns. With the resources’ section on refactoring highlighting the seemingly tedious but essential effort of cleaning up code to prevent the accumulation of technical debt, it also helped me realize that refactoring is not just a fix for poorly written code or a skill to identify bad code, but is an essential part of writing good code.

As I continue completing in-class and homework assignments for this class, and develop and edit code in the workplace, I will refer to this website to not only identify the best design pattern, but to identify the design smells and technical debt- as these assignments help with strengthening those skills with pre-written code (that we then finish and/or refactor). I will use this resource to continue practicing design patterns and refactoring, to strengthen my skills and ability to select the right design pattern to refactor my code.

Resources:

https://refactoring.guru/ – Refactoring Guru

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

For this quarter’s blog post, I chose to deepen my understanding of Unified Modeling Language (UML) Diagrams, which directly relates to current coursework in my Software Construction, Design, and Architecture class of translating between code and visual diagrams (i.e., UML class and sequence). Initially, I found both processes overwhelming and questioned the purpose of using such diagrams instead of simply reviewing the source code step-by-step. To overcome this hurdle, I looked at several resources, but I will focus on Miro’s comprehensive guide, “The Ultimate Guide to UML Diagrams,” which provided much needed clarity on the concept of UML Diagrams.

This guide offers an excellent foundational overview, and emphasizes UML Diagrams as the commonly used and encouraged visual language in software development. It identifies the 14 types of diagrams and categorizes them as either Structural or Behavioral. Structural diagrams are used to define the components of the code, while Behavioral diagrams are used to examine how the code operates over time.

A key part of this research involved understanding the drawbacks of using UML diagrams. With my own initial experience being overwhelming, complex, and tedious; it validated the discourse surrounding the love-hate relationship with UML in the software development field. Disadvantages often centered on the process being time-consuming, complex, overwhelming, and potentially ambiguous, especially as projects grow or when team members and stakeholders are not aware of coding and diagram literacy. While arguments exist for making these diagrams optional, I understand that this is a necessary and helpful step in professional practice. 

This and other resources consistently emphasize one core objective: UML Diagrams are primarily communication tools. While recognizing their flexibility, standardization, and (often) simplicity, their greatest benefit is serving as a visual aid. They create a working summary of a program/code that allows other team members and stakeholders, who may have limited time and/or specific knowledge, to look through hundreds of lines of code, to quickly grasp the architecture and operational flow.

I also learned that the perceived disadvantages of UML are the trade-off required for effective team collaboration and risk mitigation. When working through class activities and homework, working with smaller codes, I experienced some of the limitations. I fully understand how a program with 50+ classes would be completely overwhelming and time-consuming to look through and explain without an established visual reference. My personal practice of using UML class and sequence diagrams showed me the tediousness of detailing every code component, but also the value of creating and having a visual summary of the code’s building blocks.

In my future practice, I intend to apply this knowledge by creating diagrams to help me summarize the code. Whether working on class activities, homework, personal projects, and/or within a development team; I will use UML diagrams to practice summarizing and communicating code as if I were speaking with a team and/or non-technical stakeholders. Ultimately, a diagram is easier to critique and comprehend than 500+ lines of unread code spread across multiple files. 

Link To Main Resource:
https://miro.com/diagramming/what-is-a-uml-diagram/ – The Ultimate Guide to UML Diagrams

Link To Additional Resources:
https://www.theknowledgeacademy.com/blog/advantages-and-disadvantages-of-uml/ – Advantages and Disadvantages of UML: An In-Depth Analysis 

https://creately.com/guides/sequence-diagram-tutorial/#what-is-a-sequence-diagram – Sequence Diagram Tutorial – Complete Guide with Examples

https://creately.com/blog/diagrams/uml-diagram-types-examples/#UseCaseDiagram – UML Diagram Types Guide: Learn About All Types of UML Diagrams with Examples

https://creately.com/guides/advantages-and-disadvantages-of-uml/ – Why the Software Industry Has a Love-Hate Relationship with UML Diagrams

https://www.synergycodes.com/blog/why-use-uml-class-diagrams – Why Use UML Class Diagrams?

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.