Category Archives: Week 13

software design patterns

We’ve gone over a couple of design patterns in class this semester. Some that come to mind are the singleton and factory patterns, both of the creational variety. This latter half has been more focused on practical applications of software construction, taking a look into the Thea’s Pantry system that uses a microservices approach, but earlier on we were working with design decisionmaking and approaches.

A software desing pattern is a reusable solution to a problem that occurs often. The three main types of design patterns are creational, structural and behavioral. This is all well and good, but what do these types entail? I found this blog post from NetSolutions regarding the subject, and it gives a brief explanation of each as well as some examples.

Creational design patterns are solutions for the creation of objects and how they are used. The aforementioned singleton and factory patterns are creational because they dictate the way that objects are meant to be created based on the circumstances surrounding it. Singleton ensures a single instance of an object that can be called, while the factory is a sort of constructor of objects that utilizes an interface to form an object from sub-classes.

Structural design patterns relate to object composition to form better flexibility when working on a large-scale project. For example, an adpater is a structural design pattern that allows for incompatible interfaces to work together, creating greater flexibility in the program. The facade pattern is a sort of application of encapsulation and abstraction, allowing for the hiding of complexity with an interface, making it easier to work with.

Behavioral design patterns deal with separate objects and the way they share responsibility and communicate. The strategy design pattern is an example of this, where algorithms are put into a family where each algorithm is only called when it needs to be called, increasing efficiency. The observer pattern links one object to many dependents, notifying the observer object whenever any depedent has experienced any event.

It seems important to have these tools in your belt, considering that many of the problems that these design patterns solve occur fairly regularly even when developing different pieces of software. The one thing I would consider being wary of is using software design patterns at all times when you may not need it. For example, the factory pattern is best used when working on a fairly large project, but is not necessary at a smaller scale. Of course, when a project goes from small to large, a refactor may be called for, but perhaps the factory pattern is not the best tool for the job, it’s instead a builder or prototype. There is no one-size-fits-all solution, and so it’s also a skill to know when and how to use patterns and not just apply them randomly.

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

Alex JS Lint

In class, we had the in class activity about inclusive and insensitive writing. This assignment was able to open our eyes on vocabulary choices that we didn’t even notice as being potentially harmful to others that might be reading our work. This got me thinking about if anyone else has been using the Alex JS linter and if they have posted anything about their feedback and experience while using it. From my searching I found a blog post called, “Refactoring condescending language with alexjs” by Suzanne Aitchison. This blog focused on their experience with the Alex JS linting tool and what led them to start thinking about their use of words and tone when writing their work.

The blog started with what got them thinking about their use of tone and content when writing . They mentioned how they were told to focus on words such as “easy” and “simply” because to some people the task at hand might not be so simple or easy to them which can be very discouraging and have them lose motivation. The Alex JS linter focuses on, “gender favoring, polarizing, race related, religion inconsiderate, or other unequal phrasing in text” which covers most of the types of insensitive ways of writing. In the author’s experience when they used it on their own work they had 104 warning of insensitive writing that all fell into common groups. Which happened to be the use of “easily”, “simply” and “just” which we now know is insensitive to people who may not find certain tasks easy. In addition, they also ran into one of the negatives of the linter which is false positives. In this case, it was flagging words like “color” and “special” which fall under the list of insensitive language however in this context it was not. Their takeaway from working with Alex was that their default way of writing will need some work that can be taken as insensitive and Alex is a tool that helps them in making their work more inclusive.

After reading Suzanne Aitchison’s blog, I found the reading very helpful because it further pushed me in the right direction of working with more inclusive language as well as pointing out things that I did not catch when we were working on our exclusivity activity in class. I feel like as we progress as a society and we are working on becoming more inclusive tools like Alex JS will be very helpful. When we first started the in class activity I didn’t see a problem with some of the flagged words however after seeing why they were being flagged as well as reading the blog I am increasingly understanding how certain words can be taken from those that come from other backgrounds than I do. My main takeaway from this will be working on using more inclusive language and making sure that my work can be taken in a positive note from whoever reads it.

https://dev.to/s_aitchison/refactoring-condescending-language-with-alexjs-3ifp

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Writing clean code: A developers guide to readable and maintainable code

Clean code refers to computer code that is easy to read, comprehend, and maintain. This type of code is crafted to be straightforward, concise, and expressive, following specific conventions, standards, and practices that enhance readability and clarity. 

The importance of clean code cannot be overstated. When code is readable and comprehensible, it facilitates collaboration among developers and boosts productivity while minimizing errors. Additionally, easy maintainability is crucial for long term projects, ensuring that the codebase can be updated and enhanced over extended periods. The foundation of clean code lies in its readability and maintainability, as beautifully articulated in the blog “How to write clean code?” By FreeCodeCamp. In this article, we’ll dissect the principles and practices behind clean code, and give you a few tips on how to craft clean cod.

Assessing Code Cleanliness

Determining whether code meets the standards of cleanliness involves various aspects. Good documentation, consistent formatting, and a well-organized codebase serve as benchmarks for clean code. Additionally, code reviews and thorough testing contribute to identifying potential issues and ensuring adherence to best practices.

By incorporating tools, practices, and conventions, developers can create a codebase that is efficient.

Tips for writing clean code:

  1. Effectiveness, Efficiency, and Simplicity
    • Prioritize effectiveness to ensure the code solves the intended problem.
    • Strive for efficiency by optimizing resource usage.
    • Embrace simplicity for code clarity and easy comprehension.
  2. Format and Syntax
    • Enforce consistent indentation and spacing.
    • Maintain a uniform syntax throughout the codebase.
    • Adhere to consistent case conventions (camelCase, PascalCase, snake_case).
  3. Naming
    • Choose clear and descriptive names for variables and functions.
    • Avoid vague or generic names that obscure the purpose of the entity.
  4. Conciseness vs. Clarity
    • Strike a balance between concise and clear code.
    • Prioritize clarity to enhance readability, even if it means sacrificing conciseness.
  5. Reusability
    • Design code with reusability in mind, promoting efficiency in development.
    • Embrace modular and scalable software architectures.
  6. Clear Flow of Execution
    • Ensure a logical and clear flow of execution in the code.
    • Steer clear of spaghetti code through thoughtful organization and structure.
  7. Single Responsibility Principle (SRP)
    • Assign a single responsibility to each class or module.
    • Enhance code readability and maintainability by adhering to SRP.
  8. Single Source of Truth
    • Centralize data or configurations to avoid duplication and ensure consistency.
    • Simplify updates by having a single source for critical information.
  9. Only Expose and Consume Needed Data
    • Minimize exposure or consumption of unnecessary information.
    • Utilize object destructuring for selective access to required data.
  10. Modularization
    • Break down code into smaller, manageable modules for ease of understanding.
    • Foster reusability and maintainability through thoughtful modularization.
  11. Folder Structures
    • Organize the project based on features rather than file types.
    • Cultivate a clear and logical folder structure for seamless navigation.
  12. Documentation
    • Employ comments to provide context and explain the functionality of the code.

Reference: https://www.freecodecamp.org/news/how-to-write-clean-code/

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Blog #4: Disadvantages of Agile

Fundamentally Agile is a very flexible and effective methodology that allows teams to continuously provide a working model of their respective project. When compared to the Waterfall methodology, Agile may seem like a flawless approach to team development and management, however this comparison to Waterfall fails to capture Agile’s flaws. Ideally, by understanding Agile’s feats and flaws, teams can make the most of the methodology.

Agile works best when all members deliver their respective parts of the project on time. This creates pressure on the developers to reach that time quota, as a result they may be more inclined to ‘cut corners’ so to speak while developing their part. Creating faulty code (or a general product) may lead to future issues, which would likely lead to sprint backlog bloat, so the development methodology must balance the value of the work being created and the time being spent to create the aforementioned work.

On the topic of time management, Agile does not offer much flexibility while creating sprints. Sprint length is determined towards the beginning of development, this itself is an issue as developers lack the foresight to allocate enough time in a sprint to take on larger-scale projects. Sprints encourage segments of digestible work for the developer, as Bryar and Carr mention in the article Have We Taken Agile Too Far?, “rather than take the time and uncertainty to develop a new capability, they go with the skills they currently have” (Bryar & Carr). Due to time constraints, developers settle with what they’re most comfortable with, as opposed to seeking potentially more effective solutions. This damages the final product as it heavily depends on the developers’ current experience and does not promote research.

One solution to this issue would be shifting to the Epic-model. Here developers won’t face an imminent time constraint that sprints impose, rather they will take a task (a story) and aim to complete it before the team moves on to the next step (the epic). This type of work structuring does not intrinsically have a set time limit but can be integrated within the Agile methodology. The goal of combining these two types of work structuring is to create a process where developers can have assigned tasks that are components of a larger task, AND to have a flexible time limit before moving on to the ‘larger task’. Another solution would be to fundamentally change how Agile works within a team. Currently, there are very few exceptions to change the duration of a sprint period, so to shift to a variable duration of each sprint would change how Agile works. A downside of doing this would be removing the consistency between sprints, but the benefit of that is that developers may be able to take on more work or do more research into their respective tasks before delivering their first working model. As a development methodology Agile should benefit the developers, therefore shifting from a rigid (preset) working period may increase the quality of work.

-AG

Source:

https://hbr.org/2021/04/have-we-taken-agile-too-far

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

Blog #3: Kanban Expanded

While attending my previous university, Becker College, I was introduced to Scrum, Agile, and Kanban with very surface-level information. As we progressed through this current semester, my knowledge of both Scrum and Agile increased, with my knowledge of Kanban tailing behind. So I seek to answer the question of ‘What is Kanban’?

Kanban, similar to Scrum, is a type of work structuring that places importance on visual responsiveness and flexibility. Scrum and Agile run on the idea of sprints, which Kanban does not naturally have, but rather it opts to focus on a time cycle. Time cycles measure how long it will take a single task to move through all stages of development. A potential flaw here would be that if the team agrees upon many stages of development, such as adding multiple testing stages, then the average time cycle will take longer. By not imposing a static time limit, such as those provided by Sprint structuring, it encourages developers to put as much effort as possible into their respective task(s). The key to an efficient team would be to optimize these time cycles and get their average down to shorter periods while maintaining the quality of work.

Within the development process, each task is represented by a card and will move through the Kanban board as it advances in the development cycle. This board helps create the visual responsiveness that Scrum lacks. If a card is stuck in one phase of development, then fellow developers may take notice and help push it to the next stage. While visual responsiveness does help to grant a sense of worth seeing tasks being completed, it best serves as a collaborative tool between developers which further increases team efficiency.

Kanban would be my preferred choice of work structuring as I find that the Kanban board is an incredibly useful tool to both track and collaborate with your team. However, one glaring issue I do have with Kanban is the lack of a direct CD (continuous delivery). Scrum will have the Sprint Review and Retrospective which gives the development team a chance to show their current working model of the project and get suggestions for it. Kanban lacks this dedicated period to show the project and communicate with their partner. This runs the risk of high-effort work being rendered useless as it’s not what their business partner had in mind. Additionally, with the lack of a Retrospective, the team will not have a dedicated period to reflect on their progress and comment on places they may optimize their work. A solution here would be to create sprint-like periods where no work is due, but at the end of the period, developers will have both a review session with their business partner and a retrospective within the team. This increase in general communication will ensure the product will be created effectively and will meet all requested specifications.

-AG

Source:

https://www.atlassian.com/agile/kanban#:~:text=What%20is%20kanban%3F,of%20work%20at%20any%20time.

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

Goodbye Clean Code? A Student’s Perspective

As a beginner coder, I’m always learning new things about the software development world. This week, I read an article that made me think differently about “clean code,” something I thought was the ultimate goal for every developer.

The article, “Goodbye, Clean Code” by Dan Abramov, explained that while clean code is important, it’s not the only thing that matters. It’s like a tool we use to make code easy to understand, fix, and test. But sometimes, focusing too much on making code perfectly clean can actually slow us down.

I can totally relate to this! When I first started coding, I was obsessed with writing “perfect” code. I spent hours making sure every line was exactly right, even if it meant the code didn’t work as well. This approach didn’t really help me learn or be productive.

Instead of aiming for “cleanliness” all the time, Abramov suggests that we should focus on writing code that solves the problem we’re working on. This code should be clear, easy to understand, and easy to change if we need to. This way, we can learn more about coding and be more productive.

One of the things I really liked about the article was the idea of “incidental duplication.” This means that it’s okay for there to be some repeated code, especially when we’re first starting out. Of course, we don’t want to have a lot of repeated code, but a little bit is okay.

The article also talks about how important it is to work well with others when you’re coding. This is because we often share code with other people, and if we change someone else’s code without talking to them first, it can cause problems. This reminded me that coding is a team effort, and we need to communicate well and respect each other’s work.

Overall, “Goodbye, Clean Code” was a great read for me. It helped me understand that clean code is important, but it’s not the only thing that matters. It’s more important to write code that works and that we can understand and change easily. This is something I’ll keep in mind as I continue to learn and grow as a developer.

Link: Goodbye, Clean Code: https://overreacted.io/goodbye-clean-code/: https://overreacted.io/goodbye-clean-code/

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

Week 13: CS-343

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.

Clean Code

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.

Backend Unveiled: A Historical Journey from Server Stumbles to Network Pioneers

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.

Documentation

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.