Category Archives: Software Development

Smelly and Debt

I recently read an article on Opsera titled What Is Code Smell? that explores the concept of code smells and how they relate to technical debt. The article explains that code smells are indicators of deeper issues in software design, like redundant code, overly complex functions, or lack of proper documentation. While these smells don’t necessarily cause bugs, they can make the code harder to maintain or extend in the future. Technical debt, on the other hand, refers to the trade-off between short-term efficiency and long-term code quality. It’s like borrowing from the future to meet deadlines now, but it eventually has to be repaid with interest—usually in the form of extra work to fix the issues caused by the shortcuts taken.

I chose this resource because it gives a practical explanation of two topics that I’ve encountered in my software engineering classes: design smells and technical debt. These are concepts that seemed theoretical at first, but this article helped me understand how they show up in real-world projects. As I start working on my own coding assignments, I can see how these issues might impact my projects if I don’t pay attention to them early on.

The article made me realize just how crucial it is to identify and address code smells early in the development process. For example, the article points out that long methods and duplicated code can be a sign of poor design that will slow down future changes. At first, I thought that refactoring or improving code design was something only necessary when a project was nearing completion. But now I understand that addressing these problems early can save a lot of time and effort in the long run.

What really stood out to me was the connection between technical debt and long-term project maintenance. As a student, it’s easy to think that as long as the code works, it’s good enough. But this article emphasized that taking shortcuts to meet deadlines may create technical debt that leads to problems later, such as bugs or a codebase that’s difficult to work with. I’ve already seen this in my own projects—trying to push through a solution quickly, only to realize later that the code is harder to manage than I expected.

In the future, I plan to pay more attention to clean code practices. I’ll aim to refactor code regularly and avoid taking shortcuts that might seem like a quick fix but could lead to bigger problems. This approach will not only improve my coding skills but also make my future projects more maintainable.

Resource:

What Is Code Smell? – Opsera Blog

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Anti-Patterns

Source: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/

This article is titled “Anti-patterns You Should Avoid in Your Code.” It specifically mentions six of them, being: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object. An anti-pattern, in regards to software development, is an example of how not to solve a problem in a codebase. They are not a positive thing, they are examples of practices to avoid in the development process. Anti-patterns lead to technical debt, code that you have to eventually come back to and properly fix later. Spaghetti Code is the most common, it is code that doesn’t have much structure. It is called Spaghetti Code because everything is difficult to follow, files are located in random places, and when visualized in a diagram, it appears to be a jumbled mess, much like spaghetti. Golden Hammer references a scenario where you follow a certain process that doesn’t necessarily align perfectly with the project but still works well enough. This may not seem like a large issue, but is obviously not the best practice to follow because it’ll cause performance issues in the long run. You should always use a process that is the best fit for your project, even if you need to teach yourself or learn something new. Boat Anchor is when developers leave code in the codebase that isn’t actively being used in the hopes of it being needed later and thus not requiring much effort to implement when it is eventually needed. The main problem with this is when it comes to maintaining the code. It leads to the question of what code in the codebase is unused and what is being actively used. Trying to fix a bug in the system on code that isn’t even being used is a time waster. Dead code is code that doesn’t look like it’s really doing anything, but it is being called from many different places. This leads to problems when trying to modify the code because no one is unsure what is actually dead. Proliferation of Code is about objects that have the purpose of invoking a more important object, meaning it doesn’t really do anything on its own. The action of invoking the more important object should be set to the calling object. Lastly, the God Object is an example of an object that does too much. Objects should only be responsible for doing one thing, referencing the Single Responsibility principle in SOLID. 

I chose this particular source because I appreciated the way examples were clearly given along with the 6 examples of anti-patterns, and upon reviewing the syllabus the topic “anti-patterns” seemed interesting. When you’re learning computer science a lot of the time you’re learning about things that you should do and not about things that you shouldn’t do. I really enjoyed reading about these 6 examples of common mistakes that developers make in industry. It’s important to both recognize good and bad practices to ensure that your projects are properly optimized. I can definitely see myself referencing anti-patterns when designing code in the future so my code can easily be maintained. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Was it really all about frameworks?

What’s a Framework? All About Software Frameworks is an article written by Luke Stahl. I found it on dev.to, but it can also be found on the Contentful Blog. Links to both blogs are available in this post. The reason I chose this article is that I’ve heard a lot about frameworks since I started exploring web application development, and they always confused me. I used to struggle to understand what they were and what they were built for. Luke Stahl’s article answered both of these questions for me, though it also left me with a few more.

The article provides a general overview of frameworks for software development, web development, and working with APIs. However, it then pivots toward web development frameworks, which left me wondering about the differences between them. While it clearly explains the distinctions between backend and frontend frameworks, it misses covering some other differences I initially expected.

The author also includes a fairly extensive list of the benefits that frameworks bring to development, along with a brief list of challenges. For me, it’s always a bit concerning when something presents itself with so many benefits and so few downsides. Still, the benefits outlined are appealing and useful for developers.

Frameworks, as explained by Luke Stahl, are essentially blueprints or templates for a particular final product. They provide the essential building blocks and materials required to create your software or web application. A framework offers a skeleton for your application, allowing you to build functionality on top of it.

Halfway through reading the article, I began to wonder about the difference between a framework and a code library. Thankfully, and to my surprise, it seems Luke anticipated this question. He includes an explanation from two outside sources, David Fateh and Alvin Bryan. Both summarize that frameworks act as templates, while code libraries serve as tools you can use to build on top of that template.

One point that caught my attention—and that I believe is very important—is that most frameworks are FOSS (Free and Open Source Software). Being free and open source brings many advantages. Such products undergo extensive testing by a diverse group of programmers, across various applications, which increases the test sample size. This added testing leads to greater reliability, as it helps ensure that any new functionality works as intended. Another benefit of free and open-source products is the large community that often forms around them. This means that if you encounter questions or difficulties, it’s likely that someone else has already addressed them.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

The Troubles Of Learning Codebases

Often when joining a new job, you won’t be writing a new codebase from the ground up. Often we’ll have to familiarize ourselves with the preexisting codebase. Sometimes this codebase is old and needs to be updated or refactored. But how should we go about doing this? It is challenging enough to try to learn a new codebase, let alone trying to change or add to it. That’s what the question the article “Reducing The Learning Curve For Supporting Aging Codebases” by Scott Fitzpatrick aims to answer. The articles offer some dos and don’ts when it comes to trying to make it easier to learn a code base.

One of the first don’ts is to not rely on face-to face conversations and messages/email conversations. While these conversations can be helpful for developers in the moment, they offer little for someone trying to learn the codebase. Plus they can be hard to find and subject to deletion. I think the main point to take away from this article is the importance of good documentation and other resources. When it comes to making a codebase easier to understand, not just for newcomers. Having multiple avenues to try to learn from is important. Beyond just looking at the code, things like data flow and entity-relationship graphs. 

Other aspects beyond code are important too. Like good documentation on local environment set-up and system requirements/dependencies. Making these clear not only makes it easier from the newcomer, but also it helps learn about the frameworks and why they were chosen for the project. Knowing why an application uses certain frameworks and projects can help a new developer understand the reasoning and choices of the team.

Learning a new codebase is very challenging for anyone. I think this article offers good insights as to why certain practices are good and why some are bad. This also once again highlights why I think communication is the most important skill for a software developer. Being able to communicate with other developers not only through code, but through documentation is a very important skill. Making the lives of fellow developers easier by finding as many ways to communicate design and ideas. Although most developers hate writing documentation, it is a necessary evil that must be done.

I will definitely keep this in mind when writing code. Of course writing code that is readable takes precedence. But keeping up to date documentation is also vital to keep projects on track. I personally haven’t worked on a large project involving a large codebase before. So I haven’t had to write documentation for something that I didn’t write. Most of the time I don’t feel the need to write what the function or class does because I made it, so I already know. I think that’s a habit a lot of programmers have, that leads to a lot of lack or bad documentation. It’s something that I don’t have a lot of practice in, so its a skill I’ll have to start honing.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Speed Over Design

The following blog I would like to talk about is called “The Hidden Cost of Speed” by Brayden H. Hord. He begins with a quick story about a project he worked on. In this story he describes how he, in an attempt to impress his bosses and meet his co-workers needs, pushed out a product as fast as possible. This worked for the moment. His bosses were happy and he continued his work. However months later, bugs and issues are arriving daily. The software he quickly developed was being used on a daily basis, something he had not anticipated. Now all the shortcuts he had taken earlier had come back to bite him. Now he had something that was being used extensively that was built poorly. 

Now he and his team had to work laboriously to try to fix these fundamental issues. Fixing the problems but also trying to interface between management and stakeholders. The truth is that these problems could have been avoided. If he had better planned and took more time to access the needs and requirements of the project. The moral of the story is that taking time to build right saves headaches down the line. The rest of the blog goes into more detail about why planning and communication are fundamental for all software developers. 

The reason I choose this blog is because I think it highlights one of the most important factors when it comes to software development, Communication. Most software is not built by one person, but rather a team of people. What makes a good team is communication, making sure everyone is on the same page. I think this is important to remember because building without a plan is a recipe for failure. It’s easy to get excited and try to push something that works. But something built on shoddy foundations is always destined to fall. 

Sure your code may work at the moment, but somewhere down the line issues will arise. As needs and more complex architecture is needed, the holes in the code will rear their ugly head. That’s why building code that takes into account not only the needs of now, but also the needs of the future. Building architecture that makes life easier in the future, not harder. I think that this is an important lesson for any software developer to know. Because building something right not only makes your life easier, but everyone else on the team’s lives easier as well.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Understanding SOLID Principles: A Guide 

As a student learning software design, I’ve come across the SOLID principles in a few lectures, but I wanted a deeper dive to really understand how to apply them. I recently read a blog post titled “SOLID Principles — The Definitive Guide” by Midhun Vincent on Medium. This guide breaks down each of the five SOLID principles in a straightforward way, with examples and explanations that actually make sense for someone still new to object-oriented design. The article is totally in line with what we’re covering in my course, so I figured it was a great chance to see how these principles could improve my coding style now and in the future.

Summary of the Selected Resource

The article explains the SOLID principles, which are five key guidelines for designing object-oriented software that is easier to understand, extend, and maintain. The first principle, the Single Responsibility Principle (SRP), emphasizes that each class should focus on a single task, making the code simpler to maintain and update. Next is the Open/Closed Principle (OCP), which suggests that classes should be open for extension but closed for modification, allowing developers to add new features without altering the original code structure. The Liskov Substitution Principle (LSP)follows, which ensures that objects of a superclass can be replaced with objects of subclasses without causing issues in the application. Then there’s the Interface Segregation Principle (ISP), which advises against creating large, general-purpose interfaces and instead encourages smaller, more specific ones that suit the exact needs of different clients. Finally, the Dependency Inversion Principle (DIP) recommends that high-level modules should not rely on low-level modules but rather on abstractions, which reduces dependency and enhances flexibility. Together, these principles form a strong foundation for writing clean, modular code that can handle future changes more gracefully.

Why I Chose This Resource

I chose this post because the SOLID principles are really useful in building better code but can feel abstract at first. The article breaks down each principle in a way that makes them feel practical and achievable. Also, the examples in the post connect well with coding challenges we’ve faced in our course projects, especially in terms of keeping code organized and easy to debug. Seeing how SOLID principles can prevent code from becoming a tangled mess gave me a new perspective on how I approach my own assignments.

My Takeaways and Reflection

Before reading this post, I understood the theory behind the SOLID principles but not really how to implement them in my own code. Now, I can see why each principle matters and how they can actually save time by reducing the need for debugging and refactoring down the line. The Single Responsibility Principle, for example, made me think about how I often give one class way too many jobs, which then makes fixing issues complicated. By applying SRP, I can keep my classes simpler and less error-prone.

Moving forward, I’m planning to use these principles as I work on my projects, especially with the Open/Closed Principle and the Interface Segregation Principle. I can see how they’ll help me write code that’s easier to adapt if requirements change or if I add new features later. In the future, I think understanding SOLID will give me a solid foundation (pun intended!) as I move into more complex software development work.

Link to the Resource

https://medium.com/android-news/solid-principles-the-definitive-guide-75e30a284dea

View at Medium.com
View at Medium.com

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Design Patterns

Design patterns are essential tools for software developers, providing standardized, reusable solutions to common coding challenges. Rather than developing unique solutions every time a familiar problem arises, developers use these templates to write organized, efficient, and adaptable code. Design patterns are not complete blocks of code but instead serve as blueprints, guiding the structure of code in object-oriented programming and enhancing overall project organization.

according to the published article on GeeksForGeeks, the article mentions about A key advantage of design patterns which is reusability. Patterns can be applied across different projects, which saves time and effort by eliminating the need to repeatedly solve similar issues. This flexibility also allows developers to apply patterns quickly in various scenarios, accelerating development. Another benefit is standardization; design patterns create a common vocabulary among developers, which simplifies communication and collaboration within a team. By recognizing these patterns, all team members can quickly understand and follow the structure of the codebase.

Design patterns further promote efficiency by offering solutions that have been tested and refined over time. Since developers do not need to invent new solutions for frequently encountered problems, they can progress faster with fewer errors. Additionally, design patterns are designed to be flexible. They are adaptable templates, meaning they can be customized to fit specific project needs, making them a versatile tool for a variety of applications.

Types of Design Patterns

Design patterns fall into three main categories: Creational, Structural, and Behavioral.

  1. Creational Patterns focus on managing object creation to keep systems flexible and independent of object-specific creation logic. Examples include:
    • Factory Method: Allows creation of objects without specifying the exact class.
    • Singleton: Ensures only one instance of a class exists globally.
    • Builder: Breaks down complex object construction into simpler steps.
  2. Structural Patterns emphasize organizing classes and objects to create efficient, larger structures. Examples include:
    • Adapter: Enables incompatible classes to work together by adjusting their interfaces.
    • Facade: Simplifies complex systems by providing a unified interface.
    • Decorator: Adds extra functionality to objects without altering other instances.
  3. Behavioral Patterns focus on defining how classes and objects interact within a system, streamlining communication in complex applications.

In summary, design patterns help developers produce clear, maintainable, and scalable code. By adopting these patterns, developers can approach recurring problems with reliable solutions, improving collaboration, reducing development time, and creating codebases that are easy to expand and adapt. In the fast-paced world of software development, design patterns serve as a stable foundation for building robust, flexible applications

Reference: https://www.geeksforgeeks.org/software-design-patterns/

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.

What is Technical Debt

The Future you Problem

Photo by cottonbro studio on Pexels.com

Hello and welcome to a new week on this beautiful blog of mine. Today is a topic that is of interest to me and possibly everyone reading this. It could also be something you ran into during a coding project. It is called Technical debt, which is the concept of delaying or omitting work to complete a project but cause more work to do in the end. 

Let me give you an example that I have dealt with, and that you may have also dealt with. So you got a coding assignment to do right and that deadline is coming fast. So you set out to do it in the quickest and easiest way possible without a care for code layout or etiquette, it is just you working on it after all. The next day, you think to yourself that you may need to rework some facets of the code to make it run better or make it look neater. You then open up the project and look in horror at the mess you made and realize that it would take more time and effort to make it neater or run better than it would be to just continue on and get the project done. That is technical debt and yes it accrues interest.

The example was more personal and not that bad when you realize that the only price you paid is something you can’t stand to look at and also something that will take a long amount of time to fix. Like I said before it is just you working on it and as long as it works it’s fine…but what if you weren’t alone, say what if you were working in a team of 2 or 4 or perhaps a whole company amount. Then we have problems. Cause not only the debt is put upon others, but even money can be a problem if it is a company involved. 

There is also types of technical debt. Planned Technical Debt is meant to establish one presence in the market or gather feedback from customers, kinda like prototyping from my understanding. There is also Inadvertent Technical Debt when the developer is unsure of market requirements or aware of the architecture. 

Many things can cause technical debt to happen, such as poor management or the code not being reviewed well enough.  So to avoid such things it’s a good idea to 

  • Understand the Requirements
  • Understanding Decision Consequences
  • Supervising the Process

So be careful when coding a project as it may come to bite you in the future, so take into consideration the future you and help you out.

Be a Better Dev. (2020a, October 5). What is Technical Debt? (as a software developer). YouTube. https://youtu.be/2nDxKYIajoU?si=crpLGeoCewYZ_kEj

Eye on Tech. (2020b, October 7). What is Technical Debt and Why Does Tech Debt Matter?. YouTube. https://youtu.be/cdzUXv8SpjY?si=FHZ0Vl6ZVkhuSNeE

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Week 18B – C Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll continue with one I’m not the most familiar with, C! I’ve worked in small amount of C in classes at Worcester State, but have little experience outside of that. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

If you haven’t already read my other blog post on Python testing, feel free to read it right here!

Week 18A – Python Testing

For learning about unit testing in C, I consulted this article on the subject: https://interrupt.memfault.com/blog/unit-testing-basics

It seems like unit testing in C is a lot more barebones compared to Java, which in my experience utilizing C, makes sense for the language. A lot of features primarily used in Java, like object-oriented structures aren’t available in C (to my understanding, could totally be wrong).

For one major aspect, there seems to be only one assertion command in C, just simply “assert”. Theres no assertTrue, assertFalse, assertThrows, or assertEquals, just simply “assert”. And from the example given below: 

#include <assert.h>

// In my_sum.c
int my_sum(int a, int b) {
  return a + b;
}

// In test_my_sum.c
int main(int argc, char *argv[]) {
  assert(2 == my_sum(1, 1));
  assert(-2 == my_sum(-1, -1));
  assert(0 == my_sum(0, 0));
  // ...
  return(0);
}

It seems the “assert” function comes from the <assert.h> library, much like the JUnit librarys used in Java. But more importantly, it seems that “assert” is the equivalent of “assertEquals”.

It also seems like Unit Testing in C is best implemented with tools outside of a compiler for C. The ones mentioned in the article in specific were CppUTest, Unity, and Google Test. For the rest of the article, the use examples using CppUTest. It was interesting to hear one of the options being called Unity, which is the name of a game engine, which, while not written in C, is written in a mixture of C# and C++, which are both offshoots of C. Makes me wonder how testing in a gaming engine works, perhaps it’s something to look at in a future blog post, hint hint, wink wink.

CppUTest seems to implement the same SetUp() and Teardown() functions that JUnit can employ, which is really good, as these methods are important for testing multiple methods. It also seems to have more then just an Equals assertion, even though the example used is another equals example.

This gets me more interested in C, as I have been told understanding C allows you to understand other languages much more clearly. Perhaps I’ll take a deeper dive some day, who knows! Until next time, my readers~!

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

Behavior Driven Development

Behavior Driven Development ( BDD ) is a test practice that makes sure there is good quality by automating test before or during system behavior specification. BDD test focuses on facing scenarios that describe the behavior of a story, feature, or capability from a user’s perspective. When the tests are automated they make sure that the system constantly meets the required behavior.

The Behavior Driven Development Process

The BDD process has three phases to it. The discovery phase, formulation phase, and the automation phase.

1.) Discover phase: This phase is where the user creates the initial acceptance agenda for the feature. This phase is usually done in a collaborative manor, each team member is contributing.

2.) Formulation phase: This phase is where the acceptance agenda sets into detailed acceptance tests, as the backlog item gets closer to implementation. This phase also incorporates specific examples of the behavior.

3.) Automation phase: This phase is where automation tests are automated to run constantly. This is to make sure that the new system supports the new behavior.

Benefits of Behavior Driven Development

1.) Early detection of errors / defects: When you automate tests in the early stages of development process, you can identify and address the issues. BDD allows for the early detection of defects.

2.) Faster Flow and Time: when using BDD, you can reduce the errors, rework, and replan. BDD accelerates the flow of the development process. Developers can produce features / products faster and more efficiently.

3.) Stronger Test Coverage: BDD allows for a more comprehensive test coverage that focuses on the user behavior and scenarios. Both common and edge cases are tested as well.

4.) Clear understanding: BDD can be plain and clear to understand, because specific scenarios are used to describe the behavior from a user’s point of view. This helps the development to fully understand the requirements and whats going on.

Why I chose this resource

I chose this article ” Behavior Driven Development” because it provided a detail look of a very important test method that goes in conjunction with the technical and business aspect of testing. Understanding BDD is important in today’s society of software development, for giving an efficient and more user friendly user products.

Personal Reflection

This article increased my understanding of BDD and the use of it in software development. I learned a lot about how BDD strengthens collaboration and communication between the business side of things and the technical side of things. This helps to ensure that user’s expectations and requirements are met. The new found knowledge will be extremely valuable in my future endeavors because I will incorporate this method in my future projects. This will help to improve the development process and product efficiency and quality. Also, by using BDD I can make sure that all requirements and specifications are met.

The full article is here: https://scaledagileframework.com/behavior-driven-development/

From the blog CS@Worcester – In&#039;s and Out&#039;s of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.