Anti-Patterns

Anti-Patterns are “imperfect” fixes that may seem like they solve a problem, but over time, can lead to more problems where using anti-patterns are more inconvenient than not. Because anti-patterns cause problems over time, teams are forced to go back and fix them which lead to higher costs and delayed release schedule.

Types of Anti-Patterns

Spaghetti Code

Spaghetti code refers to the logical structure of the code resembling a plate of spaghetti, meaning it is unorganized and confusing. Spaghetti code usually occurs when a developer starts a project without putting much thought into the organization of the code. Although the end product may work, adding functionality may increase fragility. Using the spaghetti analogy, adding more code would be like adding more spaghetti leading to an even larger tangled mess.

Golden Hammer

Golden Hammer refers to one tool being the solution to all problems. A developer may have used a well designed piece of code to solve previous problems, but relies too heavily on it by trying to use the code for problems that do not necessarily belong. Forcing code where it may not belong can lead to spaghetti code. The Golden Hammer concept can be thought of as trying to cut a piece of wood with a hammer.

Boat Anchor

The Boat Anchor anti-pattern occurs when a piece of code is left in the code base, so it can be saved for later use. Although the code may not make sense for the program, the thought process of saving the code is if the code is needed later it can be turned on and off with comments. Some may think because a piece of code is commented out, there is no harm in leaving it. However leaving unnecessary code can lead other developers confused about what the code is intended for and over time may slow down build times. Turning the code back on may also break the code if changes were made to the point where the saved code may no longer be compatible.

God Object

A God Object is an object or a class that has too much responsibility for the program. This violates the single responsibility principle, as every object and class should only be responsible for one single part of the program. For example, there is a customer ID class responsible for the customer’s first and last name, transactions, and more. Rather than the customer ID class manage all those details, better practice would be to have customer ID be responsible for the customer’s name while a separate class is created for transactions.

Reflection

This resource was chosen because it explains what anti-patterns are, why they are bad, and listed common types of anti patterns. The article was informative as I realized I am guilty of utilizing many of these anti patterns such as spaghetti code and god object. After reading this article I am now aware of these anti patterns, and will be more mindful to not use them in the future.

Resources:

https://www.lucidchart.com/blog/what-are-software-anti-patterns

From the blog CS@Worcester – Zack's CS Blog by ztram1 and used with permission of the author. All other rights reserved by the author.

The Roots of Today’s Modern Backend Engineering Practices: https://blog.pragmaticengineer.com/the-roots-of-modern-backend-engineering-practices/

Summary:
In this blog post, we explore the evolution of modern backend practices through the lens of Joshua Burgin, an industry veteran with a rich background in backend development. The journey begins with his early days at Amazon, where accidental outages led to valuable lessons in observability and robust systems. We then travel back to 1969, witnessing the birth of ARPANET, a pioneering project that laid the groundwork for today’s distributed networks. The narrative continues into the 1980s, marking the rise of the internet and web-based computing, crucial milestones that shaped the challenges and solutions of backend development.

Reason for Selection:
This resource was chosen for its deep exploration of the historical roots of modern backend engineering practices. Joshua Burgin’s firsthand experiences, coupled with insights into the development of ARPANET and the internet, provide a holistic view of the challenges, innovations, and pivotal moments that have shaped the backend landscape.

Comments on Content:
Joshua’s recounting of the early days at Amazon offers a vivid picture of the challenges faced by developers in the late ’90s. The simplicity of tools like shell scripting and Perl, coupled with the manual deployment processes, highlights the stark contrast to today’s sophisticated backend practices. The emphasis on observability and the significance of monitoring, learned through real-world incidents, resonates with the importance of these aspects in contemporary development.

The exploration of ARPANET’s birth showcases the pioneering spirit of the engineers who laid the foundation for distributed networks. The introduction of packet switching and its impact on fault tolerance and high availability provides valuable context for current backend practices. Understanding these early challenges fosters an appreciation for the sophisticated tools available today.

As the narrative transitions to the internet’s rise in the 1980s, the challenges faced by businesses like Amazon in scaling infrastructure and serving international audiences become apparent. The change from text-based interfaces to graphical browsers reflects the transformative power of user-friendly technologies, a lesson relevant in today’s user-centric development approaches.

Personal Reflection:
This resource has deepened my understanding of the roots of backend engineering, emphasizing the iterative nature of progress in technology. The anecdotes from Joshua’s career underscore the importance of learning from failures and adapting to the evolving landscape. The historical context provided by ARPANET and the internet’s emergence serves as a reminder of the continuous innovation that defines backend development.

Moving forward, I plan to apply the lessons on observability and robust system design in my own projects. The historical insights have reinforced the idea that every complex system today stands on the lessons from earlier times, encouraging a forward-looking approach that considers the evolution of technology.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

Inversion of control is a software principle that asserts a program can benefit in terms of testability and usability if the management of an application’s flow is transferred to a different part of the program. I.O.C’s framework takes the management of an application’s implementation away from the developer. When there are interactions that require custom business logic, the I.O.C framework will use the code provided by the developer. This is the “inversion” point of the inversion of control design principle. The most common application for Inversion of control is Java servers faces. I.O.C frameworks implement low-level and problem-prone activities, it allows the developer to focus on custom business logic instead of tedious tasks.  The one thing about inversion of control is that it can confuse what qualifies as an I.O.C and what doesn’t. Some examples of inversion of control are the use of event-based user interfaces, the use of shared cache, and the use of comprehension framework. The range of development changes that qualify as I.O.C contributes to the term. I.O.C is a principle, not a design pattern- the implementation depends on the developer. I.O.C just provides high-level guidelines. Inversion of control and dependency injection are usually used interchangeably. Dependency injection is one implementation of I.O.C., it’s a technique that allows objects to be separated from other objects that they depend on.

Dependency injection suggests that instead of making an instance of class b into class a using the new operation, the object of class b should be placed into class a using one of these methods constructor injection, setter injection, and interface injection. Another example of implementation in I.O.C is the spring framework. That contains instances and manages the lifecycle of the objects in the program. The user in the configuration file provides information that relates to what objects and dependencies are used by the application like Java code. The benefits of Inversion of control are that it makes the application easier to test and maintain, reduces the amount of application code, and also decreases the coupling between classes.

https://www.theserverside.com/definition/inversion-of-control-IoC

https://www.educative.io/answers/what-is-inversion-of-control

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

What is documentation in computer science? So, documentation in computer science is the information that helps describe the product to the people who deploy, develop, and use it. This includes technical manuals and online materials, documentation sometimes refers to source information about the product discussed in code comments, design documentation, and session notes. Documentation is a way for programmers to describe their products and the process they use to create them in formal writing. Usually with early programmers, they would use notes and comments, but as programming got more complicated technical writers took over the documentation process. Documentation shows what software developers did when making the software and what users and IT staff must do when deploying and using it. Documentation is usually included in the software user interface as comments and helps the process of documentation. The information is usually divided into categories that include Evaluating, planning, using, maintaining, and installing.

So why is documentation so important? The reason why it’s important is because it provides information about a software program for everyone involved in the process of making it, developing it, and using it. Documentation records the development process and assists in basic tasks like troubleshooting and installation. With good documentation, it helps get the users familiar with the software and its features. Documentation can have a significant role in driving user acceptance. It also can reduce the burden of support teams, because it gives users the power to troubleshoot issues. Software documentation can be a living document that is updated over the software development life. The use and communication of documentation encourage users to provide developers with information on problems users have with the software and what other features they need. Developers can respond with software updates, improving their customer satisfaction and the user’s experience. 

There are two types of software documentation, internal and external. Internal documentation is used inside the company, it usually includes administrative documentation and developer documentation. Administrative documentation is a high-level administrative guideline, roadmaps, and product requirements for the software development team and project managers. Development documentation provides instructions to developers for building the software and guides them through the development process. It needs the required documents, which describe how the software should perform when tested. External software documentation helps provide IT managers and end users with information on how to deploy and use the software, It usually includes end-user documentation, enterprise user documentation, and just-in-time documentation. End-user documentation gives users basic instructions on how to use, install, and troubleshoot the software. Enterprise documentation usually has documentation for IT staff who deploy the software across the enterprise. Just-in-time documentation provides end users with support documentation at the exact time they will need it. Documentation is important because it helps keep track of all the work that was done with the software and gets updated when any changes are made. It helps developers and users get to know the software better and have a clear understanding of the code.

https://www.geeksforgeeks.org/overview-software-documentation/

https://www.techtarget.com/searchsoftwarequality/definition/documentation#:~:text=In%20the%20software%20development%20process,of%20manuals%20and%20help%20capabilities.

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

For this week, I wanted to talk about the creation of comic books, and how it relates to Software Process Management and Software Design. Within the article linked below, it describes the process of how a comic is created, and the steps needed to reach a final project. I specifically wanted to look more into this as the process is quite similar to how software is developed.

The second step is writing a plot, which is much like creating a backlog for your process, planning the beginning, middle and end of the process.

Then, its off to creating the art, which is a multi-step process, which is much like creating the code. For the artists, they need to sketch, then line, then ink and even maybe color the panels of the comic, which parallels how code will need a framework, then main code, supplemental code, and comments to build on top of each other. This process isn’t always in a predetermined order, and can vary from project to project.

And then theres editing and review. Everyone looks over the draft of the work they’ve made, and then tweaks whatever needs adjustments as needed. This process might lead to the recreation of art or code, depending on which process we’re discussing. Once a review gets a pass, they’re ready to finalize and move onto the last step, which is…

Publishing and marketing! Once you’re done, you send the finished copy of the work to consumers to receive, and perhaps you’ll even advertise it, if its not well-known. This can include things like advertisements, sponsorships, and even word of mouth.

The parallels of the dynamics in which these processes interest me a ton as someone whos also minoring in art, and wants to go into a digital design or digital-art focused field, whether it be game design or webcomics. It’s kinda awesome to see that theres a sort of venn diagram between my two passions, and that they can intersect.

EDIT: I meant to post this earlier before, but I had connectivity issues and it never posted when I thought it did. I only realized because a friend wanted to read my blog, haha. To clarify, this blog is intended for Week-12, and for both classes, not 13, it just was posted late due to issues. My apologies for this inconvenience.

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Now I know what everyone is thinking, ‘You lied in your last blog.’ Yes, I did, and guess what? This is my blog, so that’s okay. You see, I could not pass up on this beautiful opportunity to kill two birds with one stone. As you may remember from my last blog, I complained about how hard it was to come up with topic ideas for CS-343. Well, well, if by some miracle I read that if topics intertwine between your two classes (343/348), we could count one blog for both classes (shoutout Prof Wurst :)).

Enough yapping, clean code time. I believe it was only a year ago when I first started taking coding seriously, and I can recall how awful my code looked. It worked… but if you wanted to debug, you had to pray before opening it. We are talking about one-function programs, with no formatting and variable names that would drive any professor mad. I quickly realized how important clean code was after watching some YouTube videos and seeing how much easier debugging was if your code had a good flow and was properly formatted. This is where I stopped when it came to clean code, unknowing that there were 100+ other factors that all combine to make clean code.

While exploring LinkedIn, I came across this article by Oleabhiele Donald titled ‘Benefits of Clean Code In Your Application Development.’ I gave this a full read and was really surprised about all the little ways I could make my code even better than it already was. Now I 1000% recommend giving it a full read, but I’m going to talk about some of the techniques that were mentioned that I didn’t know at the time or found most beneficial to me.

Use comments sparingly:

• Limit the use of comments to when necessary, ensuring clarity and conciseness. Overusing comments can clutter the code, making it harder to read. Aim for clear and concise comments that add value.

Write small, focused methods:

• Break down larger methods into smaller, focused ones, each with a single responsibility. This approach improves code understanding and facilitates easier modification.

Use unit testing:

• Incorporate unit testing practices to verify code functionality and prevent the introduction of errors. Well-designed unit tests contribute to clean and reliable code.

Avoid duplication:

• Identify and eliminate code duplication by utilizing methods, classes, and inheritance. Reducing duplication enhances code maintainability and modifiability.

These techniques stood out to me mostly because they were things I just didn’t think about. I love to keep a list on my desktop notepad that always reminds me of some of the key steps to clean code.

Why Clean Code? This a very simple answer thanks to the article, clean code is important enhances readability, making it easier for developers to understand, maintain, and collaborate on software projects. It also improves efficiency, scalability, and reduces the likelihood of introducing bugs, ultimately leading to more reliable software and a happier programmer.

Source: https://www.linkedin.com/pulse/benefits-clean-code-your-application-development-daniel-donald/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

SOLID is an acronym that stands for the 5 different principles that help write high-quality, maintainable, and scalable code. These include Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP). Each provides their own benefits and work in tandem together when designing a program.

SRP states that a class should only have one responsibility, meaning only one reason to change. This helps prevent a class from having too many responsibilities that can affect each other when one is changed. Following SRP ensures that the code will be easier to comprehend and prone to fewer errors. However, it is harder than it sounds to fulfill this principle. The quickest solution to adding a new method or functionality would be to add it to existing code, but this could lead to trouble down the road when trying to maintain the code.

OCP states that software classes, modules, functions, etc. should be open for extension but closed for modification. This is essential because it allows entities to be extended without modification so that developers can add new functionality without risking the chance of breaking the code. Adding an additional level of abstraction with the use of interfaces help design the program to provide loose coupling.

LSP states that any instance of a derived class should be substitutable for an instance of its base class without affecting the program in a harmful way. The importance of this principle revolves around the ability to ensure the behavior of the program remains consistent and predictable. Unfortunately, there is no easy way to enforce this principle, so the user must add their own test cases for the objects of each subclass to ensure that the code does not significantly change the functionality.

ISP focuses on designing interfaces that are specific to a user’s needs. Instead of creating a large interface that covers all methods, it is more beneficial to split up the methods across smaller, more focused interfaces that are less coupled. For example, having too many methods in an interface can sometimes cause issues in the code, so separating the methods into individual interfaces that can be implemented by a certain class.

DIP states that high-level modules should not depend on lower-level modules but should depend on abstractions. This approach aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend. An important thing to note is that both high-level and low-level modules depend on abstractions. Dependency Inversion utilizes the SOLID principles which in turn leads to a more refined and maintainable code.

This is related to the class subject in many ways because it works as a guideline to write the most convenient code for programmers to maintain. Testing the aforementioned code is a simpler process when abiding to the SOLID principles as well. It also allows for easy scalability, making it essential for large code sets that evolve and become more complex over time.

SOLID Design Principles: The Single Responsibility Explained (stackify.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.