For this quarter’s blog post, I chose to deepen my understanding of Version Control systems (VCS), specifically how tools like Git and platforms like GitHub and GitLab function within the software development lifecycle. Learning new tools and techniques takes continued practice, and learning Git was no different. My goal with this content is to strengthen my knowledge of the core concepts and purpose behind these vital tools, which is what my Software Process Management course is currently emphasizing working with and practicing.

I focused on a website from GitHub itself, which explained what version control is. I chose this resource because it provides a foundational explanation of VCS, its types, and current popular tools. This article, “What is Version Control?”, defines VCS as systems that give members working on the same project complete visibility into the history of the code, and centralize all members’ work. It describes how Distributed Version Control Systems (DVCS), like Git, are essential for software development. It explains key concepts including the ability to track every change, work independently, propose code additions, and safely integrate changes while preventing conflicts. In other words, the process of commits, branching, pull requests, and merging; all fundamental processes we are focusing on in my course.

Before this course, and diving into resources, my understanding of Git was minimal. I gained a much deeper grasp of how VCS tools are both seen as a safety net and a coordination tool. Branching is one of the most important steps within the software development process, as it allows a team (of however many or little) to work synchronously on a project without fear of overwriting or corrupting the main code. Allowing team members to work independently, cohesively, and in a time-efficient manner; while also being able to access and review modifications made by other members via accessing their branch of the project. 

Although all of the information is important, the section on best practices particularly resonated with me. While working with Git, we are encouraged to save changes in small increments, making sure to write a helpful commit message, rather than making large changes and saving at the end. Seeing this best practice emphasized in the article reinforced its importance. Using this technique significantly reduces conflicts and makes debugging errors and explaining changes much simpler. 

I expect that I will continue using Git throughout my professional career, and I plan to apply this understanding immediately as I continue working with Git in class. My goal is to use this knowledge and helpful techniques to practice improving my execution and workflow. I will prioritize working in small increments, committing those small changes, and reviewing my changes to ensure my progress is meeting expectations and to also contribute to the team’s collaboration.

Link to Main Resource:
– https://github.com/resources/articles/software-development/what-is-version-control – What is Version Control?

Link to Additional Resources:
– https://www.cbh.com/insights/articles/collaboration-tools-changing-the-workplace-landscape/ – Collaboration Tools Changing the Landscape of the Workplace

– https://www.planview.com/resources/articles/software-development-collaboration-tools-a-detailed-buyers-guide/ – Software Development Collaboration Tools: A Buyer’s Guide for Empowering Agile Teams

– https://fullscale.io/blog/benefits-collaborative-software-development/ – The Benefits of Collaborative Software Development

– https://www.geeksforgeeks.org/git/version-control-systems/# – Version Control Systems

– https://www.geeksforgeeks.org/git/what-is-git/ – What is Git?

– https://github.com/resources/articles/software-development/what-is-software-development – What is Software Development?

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.