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.

During this last week of class, I have been learning about clean code and how to write it as well as edit my previously written code in order to follow these guidelines. Clean code is exactly what it sounds like. It is code that is easy to read and understand, and isn’t too complicated or formatted poorly. Learning how to write clean code is going to be vital in working in the computer science industry. Everyone in this industry works with another programmer at some point in time, so having clean code will make their life and your life easier. While researching more about how to write clean code, I found a website called freecodecamp that does a great job explaining attributes of clean code while also giving examples. On top of explaining how to do it, it also has a section explaining why you should care about writing clean code. Personally, this really helped me understand why clean code is needed and why it is very important to understand.

The three main aspects of clean code are effectiveness, efficiency, and simplicity. Effectiveness is pretty self-explanatory. It means that the program should be able to solve the problem that it was designed to solve, otherwise it isn’t helpful. Once the program is considered to be effective, we need to also make sure that it is efficient. If a program solves a simple addition problem, but takes 36 hours to run, the program isn’t efficient as there are much faster and more simple solutions. If your program is post effective and efficient, then you also need to make sure that it has simplicity. While most sites will have different qualifications for simplicity, I think freecodecamp has most of them. Freecodecamp wants everyone that is trying to write clean code to ask themselves these questions about the code:

1. “Can you easily understand what the program does at each line?
2. Do functions and variables have names that clearly represent their responsibilities?
3. Is the code indented correctly and spaced with the same format all along the codebase?
4. Is there any documentation available for the code? Are comments used to explain complex parts of the program?
5. How quick can you identify in which part of the codebase are certain features of the program? Can you delete/add new features without the need of modifying many other parts of the code?
6. Does the code follow a modular approach, with different features separated in components?
7. Is code reused when possible?
8. Are the same architecture, design, and implementation decisions followed equally all along the codebase?”

While there are a ton of other ways that you can improve your code, these are the 3 main factors. Without these 3 foundational factors, you wouldn’t be able to write clean code which would make life harder for you and for everyone that reads your code.

Synopsis: https://www.freecodecamp.org/news/how-to-write-clean-code/#what-does-it-mean-to-write-clean-code-and-why-should-i-care

From the blog CS@Worcester – One pixel at a time by gizmo10203 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.

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.

Software Process Model

A software process model is an abstract framework that gives steps on ways to plan software development processes and how they can be organized and executed. There are different types of software process models but all include some form of:

• Specification – Defining what the system should do
• Design – Defining the structure of the system
• Implementation – Implementing the system
• Validation – Ensuring the system works as intended and that the system is what the customer wants
• Maintenance – Changing, modifying, updating to keep up with the customer needs/fixing bugs

Types of software process models

There are many different types of models that are available to be used by organizations. Some allow organizations to use the model directly while others are more flexible, allowing organizations to create custom steps that are more specific towards their needs.

Software processes are typically specified using Software Development Life Cycle (SDLC) models. These models specify the different steps of the software development process and the order they are executed. 

Waterfall Model

The waterfall model breaks down software process activities into sequential phases. Each phase depends on the outcomes of the phases before and cannot be started until all phases prior have been completed. Each phase corresponds to a software process. For example, the first phase would be specification/requirements analysis because developers cannot create a system without knowing its intended function. Once that step is completed, then the next phase can be started and so on.

V Model

The V model is similar to the waterfall model where steps are followed in a sequential order. Initially after each step, the model progresses downwards to move onto the next step. Once the the coding/developing stage is complete, the model then bends upwards to create a V shape. This model highlights the relationships between each phase of the development life cycle and its corresponding phase of testing. The downward process is called the Verification Phase, while the upward process of the model is called the Validation Phase which are completed by developers and testers, respectively.

Agile

Unlike the two previous models, Agile is not a model with specific steps to follow. Rather Agile is a broader term for a set of methods and practices that encompasses values from the Agile Manifesto. These values helps teams to react quickly to any unforeseen changes, while reducing risk. The software development approach to Agile is usually rapid and small cycles. Doing this results in more frequent releases with each building upon the previous releases. Agile can be implemented by using frameworks such as Scrum and Kanban.

Reflection

I chose this resource because before simply listing different types of models, it clearly defined what the software processes are. This ensures a foundation is established. Although only three of the models in the article are listed above, there are several more models which I found interesting as I was unfamiliar with some of them. Because organizations use different models, being aware of the more popular ones will be beneficial in the future.

Resources:

https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/

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.

In the realm of software development, the challenge of deciphering convoluted and tangled code, often referred to as “spaghetti code,” has persisted. This final blog explores the significance of writing clean code—a practice that not only caters to machines but, crucially, facilitates human collaboration, ensuring project success.

I selected this resource since it delves into the importance of clean code in software development. i feel as though it emphasizes readability, consistency, and meaningful naming conventions, addressing the challenges posed by complex and unclear code structures. The text advocates for clean coding practices that enhance collaboration and ease of understanding among developers.

i picked this since it stood out due to its comprehensive coverage of clean coding principles, ranging from intuitive code structure to the strategic use of comments and robust error handling. Its relevance lies in providing practical insights into writing code that is not just functional but also maintainable and adaptable, aligning with the collaborative nature of software development.

The content underscores the pivotal role of developers in the software industry and how clean code is indispensable for creating software with easy usability. Consistency, meaningful names, simplicity, strategic comments, and robust error handling are identified as key components of clean programming. The emphasis on collaborative practices, such as code reviews and refactoring, highlights the continuous learning and improvement inherent in writing clean code.

The use of AI in code reviews and automated testing aligns with current technological trends, enhancing the efficiency of maintaining clean codebases. The resource effectively communicates that writing clean code is not just a good practice but a fundamental aspect of sustainable software development.

This material reinforces the profound impact of clean coding on the collaborative and productive aspects of software development. It has heightened my awareness of the long-term benefits of investing time and effort in writing clean code. I understand that clean code is not just about pleasing aesthetics; it’s a strategic approach that ensures maintainability, efficiency, and scalability throughout the software development lifecycle.

https://reflectoring.io/clean-code/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

For this blog post I will be discussing the Practice, Practice, Practice pattern. This pattern essentially says that you should practice, obviously. The goal is to get better and better and to build concrete skills in new areas. Looking back on all that I have learned I noticed that there was one thing that I nearly could have always done more of and that was practice. The initial blurb in this pattern says ” The people we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—and because of this they do get better. And then to complete the circle, the better they get the more they enjoy performing the basic moves over and over again.”(Apprenticeship Patterns) From this valuable quote I have learned that those that are truly skilled have put in a lot of time devoted to practicing. Within this year if I want to do anything, that is practice everything that I have learned at WSU. From basic java skills to git workflows. I see that with open-source software this may be a good opportunity to do such things. WSU has provided the resources and has made becoming a master in computers that much more of a reality and a valuable one at that. By practicing on my own I can learn from my mistakes and give myself the comfort to save space and observe my own mistakes. Then, by looking to the provided resources I can look where to emulate a more masterful understanding of computers in whatever specific area that I may wish to practice in. I can even look back on where I can specifically improve based on grades and the hindsight of completing a course. In the context of this specific course, it is working on a large scale project that are maintained by large groups of people. I understand that the traditional way of getting a position at some type software developer job is a good way to get in that practice but with where I am at now and where I want to be I don’t think that would be an optimal environment for me, at least not yet. If I have learned anything, its that I can get by on a set structure that school provides, but where I find the most growth and improvement is in the setting in which I put myself in.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the thought-provoking chapter titled “Draw Your Own Map” from the book “Apprenticeship Patterns.” This chapter delves into the notion that your envisioned career path may not align with your current employer’s trajectory and provides insights on how to forge ahead in pursuit of your own career aspirations. The author emphasizes a crucial point: it is solely your responsibility to identify what you want to achieve in your career and then take deliberate steps to initiate progress towards those goals. However, this does not discount the significance of seeking guidance from mentors or individuals who can offer valuable insights and steer you in the right direction.

One noteworthy aspect highlighted by the author is the tendency of successful apprentices to gravitate towards companies that share a “certain family resemblance.” This concept is rooted in the idea that apprentices make career choices based on their own values and principles. Put simply, the author suggests that as a programmer, it is unwise to join a company that lacks shared passion and values, as it will likely lead to a lackluster work experience. Another aspect that resonates with me personally is the emphasis on gracefully transitioning from one company to another while maintaining positive relationships with previous employers. This is particularly significant in the industry, as a tarnished reputation with former employers can potentially limit future opportunities.

On the whole, this chapter conveys a compelling message: change is a necessary catalyst for personal growth. While change can be daunting, it is an essential ingredient for becoming the person you aspire to be. The author offers a practical exercise to facilitate this process: write down a list of potential career paths that your current job can lead to, and critically evaluate if any of them align with your long-term vision. Overall, this chapter reinforces a valuable lesson that I have personally experienced: sometimes, in order to evolve as an individual, it is necessary to move on from your current employer, even if it means accepting a temporary reduction in income. The valuable experiences and personal growth gained in pursuing your new path far outweigh any financial considerations.

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

The pattern I read for this week was “Use Your Title”. It was about how to not let your job title at work affect how you work, and continue working as hard as you would if your title was something lower. I really enjoyed this pattern as I have never had this problem, but actually the opposite. I don’t let it get to my head because I always feel undeserving of what I get. I always feel like I can do better, and that I am no different from everyone else. It was interesting to read about how titles can have the opposite effect on people as well though.

This pattern taught me that titles do not matter, and whatever your title is, you should strive to be the very best that you can be. It has not changed the way I think as I never let a title get to my head, but it has caused me to think about others that I know this affects, and how this could really be of help to them. I think I should change the way I think that I am not deserving of what I get though, as I constantly work for what I get, and deserve everything that I have worked for. It isn’t like I am just doing nothing, and putting no work in at all. 

There was nothing that I particularly disagreed with in the pattern. In fact, I agreed with everything that was stated in it. Titles should never get to people’s heads, and they should not make you work any less hard. It is fine to be happy about your new title as you have worked hard for it, but you must know that I can change and go at any moment. To continue rising, you must continue putting in the work, and strive for even more. You should not get lazy and complacent of where you are right now. I think this pattern does not just apply to software craftsmanship, but everything. Everyone should read this pattern, as the issue of titles can be seen in every work area, and there will always be someone that lets it get to their head.

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

The pattern I read for this week was “Nurture Your Passion”. It was about how to keep your passion for software craftsmanship, while also letting it grow at the same time. It lists many ways to grow your passion from working on what you like to seeking out kindred spirits. I really enjoyed reading this pattern because passion for your job is something we all seek our entire lives. I went through all the pain and struggles all the way through college for a chance to get a job I am passionate about. Once you get the job though, you need to be able to keep that passion for your entire life, and even grow it into something more.

This pattern taught me many different ways to grow my passion for software craftsmanship. My favorite was studying the classics as I hadn’t really thought about it. That allowed me to change the way I think, and I am thinking about reading some books made by software developers of the past to learn from their passions. The way to a brighter future is by studying the past, so I should use the words of past software developers to help myself and improve myself. I thought the tip about seeking out kindred spirits is great too. You should try to find different people with similar passions as you, so you both can help each other grow, and keep what you are doing from getting boring. The more people that can help you grow your passions and help you learn, the better off you will be.

There was nothing that I particularly disagreed with in this pattern. I thought it did a good job giving different ways to grow your passions, and great reasons why it is important to do. Without growing your passions, it will soon leave you unpassionate, and lead to a decrease in your work. Passion that is ever growing for what you are going to be spending the rest of your life doing is extremely important, and it is necessary to have. I think everyone should read this pattern because it can be applied to everything, not just software craftsmanship.

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