For this quarter’s blog post, I decided to dig deeper into Application Programming Interfaces (APIs). An API is a software translator that allows two applications to communicate with each other. It lets a client (i.e., web browser) request information that is held in a database, and get a structured and (hopefully) desired response back. 

I chose this resource, API Architecture Patterns and Best Practices, as it describes API, its layers, the components within API, types of API architecture, and best practices when using API. As this resource states, APIs have a few conceptual layers that allow for communication to happen, including: Interaction, Application, Integration, and Data Layers. 

There are a few resources I have compiled to further understand API, and this first resource was a great foundation for understanding the topics listed above and to prompt further exploration into a specific type of API Architecture: Rest API. This design has different names it goes by, but I wanted to further explore this as it is the design my course, Software Construction, Design, and Architecture, is heavily focused on. We are currently understanding API via an incredible resource at Worcester State University, called Thea’s Pantry. 

A resource by IBM, “What Is Rest API?,” gave a very helpful walkthrough of what REST API is and how it operates. Rest API uses a representational state transfer (REST) design, using HTTP method calls including: Put, Post, Get, and Delete. These HTTP method calls provide a straightforward request and response communication style between the user’s client and server.  

Understanding this topic was surprisingly exciting for me. Not only because this is a skill I need to have as a prospective software engineer, but because the more I practice and understand the purpose and components of API’s, the less overwhelming it actually feels. While exploring this topic in class, all of the necessary files, components, and everything that comes to be “API” were very overwhelming to learn within 75 minutes; and even more so to try and piece together on my own time.

There are a lot of pieces to the puzzle, but once I become more adept at putting them together, I know and can see that the outcome of such hard work will amaze me. It already amazes me! It also helped gain insight into how webpages operate, and sparked a growing interest in understanding the skeleton of webpages. I now can somewhat understand the F12 button, and not freak out when accidentally pressing it!

I plan to continue practicing and developing API on my own time. There are a variety of tools to begin practicing, following along with a guide, or trying to create on my own; and I thankfully have resources from my class to help with this as well. I want to develop my skill to not only write code, but also to clearly explain how all the pieces communicate with each other, the computer, the client, and the user. It is a fascinating system that will help me reach my goal of soon developing my own platforms. But, one step at a time!

Main Resources:
API Architecture Patterns and Best Practice – https://www.catchpoint.com/api-monitoring-tools/api-architecture

Thea’s Pantry – https://www.worcester.edu/campus-life/theas-pantry/

What is REST API? – https://www.ibm.com/think/topics/rest-apis

Additional Resources:
Back End for Beginners: Connect Your Front End to your own API – https://www.youtube.com/watch?v=8PMLZ3hkKXM

Caching – System Design Concept – https://www.geeksforgeeks.org/system-design/caching-system-design-concept-for-beginners/

HTTP messages – https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages

RESTful APIs in 100 Seconds // Build an API from Scratch with Node.js Express – https://www.youtube.com/watch?v=-MTSQjw5DrM

What is Scalability and How to achieve it? – https://www.geeksforgeeks.org/system-design/what-is-scalability/

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 decided to speak more about the principles of clean code. The resources I discovered when exploring this topic surprised me. I have understood the general concept of writing code that is easy to read, maintain, and understand from the start of my time here at Worcester State University. However, now I have been introduced to the more specific and controversial perspective explained by Robert C. Martin (aka, Uncle Bob). My goal with the resources I chose was to compare Uncle Bob’s approach against how clean code is viewed in more general practices.  

This resource, Clean Code: The Good, the Bad and the Ugly, explores Uncle Bob’s perspective on clean code, while the author identifies components they see to be good, bad, and ugly. The resource “Clean” Code, Horrible Performance, tests Uncle Bob’s clean code components and explains how it impacts performance. Lastly, there are two other resources that give examples of general practices of clean code.

From what I understand, the core idea of clean code is that people read code way more often than they write it, so it is important to prioritize clarity. However, on the other hand, Uncle Bob’s perspective advises for small functions and almost no comments. Some of Uncle Bob’s advice is similar to general clean code practices, but this specific advice leads to some conflicts.

The first two resources showed that sticking too closely to Uncle Bob’s principles can actually lead to decreased performance. This happens due to highly fragmented code (following his principles on small, single-purpose functions), which can be less efficient for the machine to run. The main takeaway from these conflicting views is that Uncle Bob’s ideas are helpful guidelines, but they are not universal rules. It is important to understand the trade-off between absolute readability and optimal performance based on the focus and needs of the project you are working on. 

The advice against using comments genuinely surprised me. In one way, comments are a great way for beginner coders to track the purpose of their code, and to boost their understanding of certain components (i.e., loops, methods, functions, classes, etc.). At least, that is what I often used comments for when practicing coding alone. Now I understand that, when working on a team, those initial comments can quickly become confusing and unhelpful. If a comment is not deleted or updated when the code changes, it becomes misleading. Your code should describe itself using good variables, functions, and method names. If you need a comment to explain what each part of the code does, that may be a sign of poor coding design. 

I had intended to use clean code as I continue practicing coding. However, now I have more tools under my belt to make sure my code is not just digestible for me, but also digestible to someone who may need to read or update my code without me there to explain it.

Main Resources:
“Clean” Code, Horrible Performance. Many programming “best practices” taught today are performance disasters waiting to happen – https://www.computerenhance.com/p/clean-code-horrible-performance

Clean Code: The Good, the Bad and the Ugly – https://gerlacdt.github.io/blog/posts/clean_code/

Messy Code V/S Clean Code in MVC context – https://medium.com/highape-tech/messy-code-v-s-clean-code-in-mvc-context-9ad99079a4f8

What Is Clean Code? A Guide to Principles and Best Practices – https://blog.codacy.com/what-is-clean-code

Additional Resources:
Polymorphism in Java – https://www.geeksforgeeks.org/java/polymorphism-in-java/

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 further explored the importance of developing a strong software team. The resource I chose is an article called “Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.” I chose this resource because it offers insights into how groups are organized for success, as well as the drawbacks of specific approaches that are used in current day. Building strong software development teams is a topic that ties directly into my current course, Software Process Management, discussions on team structures and project methodologies.

This article identifies and describes core characteristics of high-performing software engineering teams. It stresses the importance of traits like clearly defined roles, balanced seniority, responsibility and ownership, reasonable size teams, trust, transparency, strong leadership for effective team cohesion, executing and developing skills, to build and maintain a team environment of honesty and shared responsibility. 

This article strongly emphasizes the importance of having small and manageable sized teams, and provides a visual to better understand how bigger teams equal to higher chances of miscommunication and reduced efficiency.

Two common flawed approaches are analyzed (Single-Discipline Teams and Manager-Led Cross-Functional Teams) and compared to the optimal approach: Self-Managed Cross-Functional Team, via strong pros and cons lists. The key takeaway of this is to express that when team members understand their contributions to company and project goals, they are better equipped (with hard and soft-skills) to organize themselves and produce results efficiently.

This resource also reiterates the importance of team structure and team size, something of which I am directly experiencing within my POGIL-approach class, and class discussions on Agile and Scrum methodologies. This article provides the professional, industry-level validation for this very concept: the benefits of small, cross-functional groups for project completion.

My takeaway from this article is the benefits of self-managed cross-functional teams, and how unbalanced teams can lead to an increase of overworked members, lack of team cohesion, and decreased value and motivation into the project development and goal. Group work can be challenging, and even more so when the core values of a functional and strong team are absent. The article also emphasized the importance of strong leadership, as poor and ineffective leadership can be the root cause of common issues like “quiet quitting,” where team members feel the only way to bring attention to the poor leadership environment. This challenge is present, much too common, in fields outside of software development teams. 

As someone who sometimes struggles in team settings, due to worries about offering incorrect and simple input, I will make sure to understand the value I contribute to the team and not steer from contributing my knowledge. Even if my contributions are “simple” or “incorrect”, this will provide an opportunity to connect with and learn from my teammates, build an environment of trust and open communication, and strengthen my own leadership skills. As leadership does not start and end with the managers/leads of the team.

Main Resource:
https://medium.com/geekculture/better-software-engineering-teams-structures-roles-responsibilities-and-comparison-with-common-fb5c3161c13d – Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.

Additional Resources:
https://www.inc.com/peter-economy/why-quiet-quitting-is-actually-a-leadership-failure-and-how-to-fix-it/91181524 – Why Quiet Quitting Is Actually a Leadership Failure — and How to Fix It. Quiet quitting is a virus that affects entire organizations. Where it stems from might surprise you.

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.

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 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.