While the title of this blog post doesn’t seem like it has to do with Software development, trust me it does. I was reading a blog post by Arvind Singh Baghel called “Software Design Principles DRY and KISS” which talks about important design principles and how they are violated and good tips on how to achieve these principles. DRY stands for “Do Not Repeat Yourself” which basically means avoid using the same code or iterations of the same code over and over or in different places since it wastes time for the people reading it and the software itself and creates unnecessary complexity. KISS stands for “Keep It Simple Stupid” which in terms of software development means keeping methods small and avoiding complexity. I chose this blog post because it lays of the important principles that keep designs of code simple and easy for later changes or if they are read by another person which is something that I feel I want to work on being better about. Looking back at a lot of my code, I rarely kept my code simple or avoided repeating myself for simplicity and time saving, but that would end up wasting more time later when I would need to go back and make changes or trace my code. The code that I would make would have methods that would use the exact same lines of code with minor changes or no changes at all, which made following the code that much harder since I had to look at each implementation of the same code and see what was slightly different. I would also try to fit as many different things into a single method as possible which would create extremely long methods. When methods would fail test cases these long methods of repeated code would make it much more difficult to figure out where the real issue was and took more time than it would have if I decided to split up the methods and not reuse code throughout the program. Simplicity seems to be a major key in any good design regardless of what you are designing and these rules of DRY and KISS would have saved me a lot of time on projects and coding assignments had I applied them and not tried to take the easy way out. I already have worked on applying this to my current projects and it has made a huge difference in both my experience with coding and the time and energy it takes to complete a project.

Link to blog post mentioned: https://programingthoughts.wordpress.com/2018/04/15/software-design-principles-dry-and-kiss/

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

When you think of the word smell, your first thought
is probably not computer design. Design smells are a vital part of designing
clean, readable and re-usable code. In total there are 7 main design smells.
They are rigidity, fragility, immobility, viscosity, needless repetition,
needless complexity and opacity. The reason they are called smells is because when
there is a “high smell” of one of these terms it means there is probably poor
code. According to Wikipedia, the origin of the term design smell was originally
from code smell which was in Martin Fowler’s book Refactoring: Improving the Design of Existing Code.

(https://en.wikipedia.org/wiki/Design_smell)

In this book the term code smell was essentially the
same as a high smell/bad smell would indicate a deeper problem in the code,
rather than what was on the surface.

The first design smell is rigidity. When code is has
high rigidity, it means there is often a lot of code that is hard-coded in. This
causes the code to become rigid because small changes can cause a much larger
impact through-out. In order to avoid a high rigidity smell, code should be
dynamic and able to fit the system it is in. If there is too much hard-coding
it will be very tough to make changes later on.

The next design smell is fragility, and this is
similar to rigidity with a few exceptions. Fragility is the tendency of code to
break when a small change is made, similar to rigidity. The main difference between
these two is with fragility, the areas that suffer are often unrelated to the
changes made. With rigidity, the changes directly affect the code related.

The third design smell is immobility. For a lot of
code to be useful, it needs to be able to work with other systems as well. With
immobility, the code or program could be beneficial to other areas but there is
too much effort/risk to be able to successfully integrate it.

The fourth design smell is viscosity which means that
code can become “thick” and hard to work with. When you are designing a
program, you want to be able to modify it along with the design, but “hacks”
can be done to quickly fix the issue. The problem is that the more hacks in the
program, the less the program sticks to its design. This cause a lot of extra
code and the program becomes highly viscous. It is important to know the impact
of these small hacks and how to limit them.

The next design smell is needless repetition, which is
pretty straight forward. In a program, you do not want to have to repeat the
same code over and over. Instead find ways to integrate and abstract the code
for re-usability.

The next design smell is needless complexity, again,
pretty straight forward. This can happen when a program includes sections that
are not yet utilized but “could be”. That extra code is clogging space and has
no benefit.

The last design smell is opacity. Opacity simply means
to become less clear. This can happen when there are many changes to a program
but no effort to keep the code clean and organized. Eventually the code will
become foreign to all that had worked on it before without proper care.

Keep all these design smells in the back of your mind
next project!

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

SOLID is an acronym for a set of important design principles. Paired together they create a framework for worry free code, and by “worry free” I am speaking of code that would trouble you if any changes needed to be made. In the world today things are constantly changing and being updated and so should your code. If that’s the case then any code you write should have the ability to be edited without causing a complete overhaul of your whole program. Basically what you want to avoid is trickle down effects, and unlike trickle down economics, this is real. If you change one thing or responsibility of a class or variable and that causes a cascade of continuous changes and troubles, then you are experiencing this trickle down effect. To help with this issue is the first design principle in the acronym, Single Responsibility Principle.

Single Responsibility Principle is exactly what it sounds like. Give your classes and methods a sole responsibility so that if they are changed it will only effect that method or classes responsibility. If a class or method handles multiple responsibilities then changing the design of one part may be cause to change the entire entity. 

A crude example would be a Rectangle Class. Let us say you have a constructor to build a rectangle object and all it does is take arguments for height and width. However, you also add if and else statements in the constructor to see if the dimensions make a square and printing a confirmation message if it is. Perhaps you even write “if (myShape.isSquare())..” to send the object to a method to, but this is giving the constructor more than one responsibility. If you decide to change the placement of the square check then there will either be duplicated code or you will have to edit the constructor to pass the isSquare result to other methods. Doing any of this would result is test case changes if you were testing the code. In this scenario it is best to have the constructor just be the constructor and to dedicate the square check to its own method like isSquare. In this case if changes were made then only a single class would require changes and not several that are connected in a convoluted fashion.

I think the Single Responsibility Principle is a must know. I remember beginning coding is CS140 and Data Structures and I would try to get as much done in as few methods as possible by cramming in multiple functions into them. I thought the less methods the better but I was so wrong, it’s worth so much more to have many separate methods and classes that each have a sole function. This way code is organized, easy to arrange, and simple to implement or change.

SOLID Design Principles Explained: The Single Responsibility Principle. (2018, December 17). Retrieved from https://stackify.com/solid-design-principles/

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Writing software is fun. Mostly.

When I look back on the projects I’ve made, a couple big ones stick out which were mostly not fun. For example, I made the mistake of trying to build an Android app before I fully understood what a class is. Design patterns were not even something I had considered. The consequence was a fairly simple app with code that was supremely complicated and confusing.

For my next project, I tried to do better with the lessons I had learned. I continuously had errors that I didn’t understand; errors that were seemingly unrelated to the changes I had made. After a couple weeks of struggle I deleted all my files and uninstalled Android Studio. The frustration was so bad it made me want to quit programming. The frustration could have been prevented.

This is where tests, and specifically Test-Driven Development (TDD) could have saved me.

James Grenning has a blog post discussing how he feels about TDD, after years of writing software without it. TDD forces you to think through what you want your code to do. If you can’t test your code it’s likely a sign of bad design, so TDD indirectly leads to a better software architecture. Tests describe what the code is supposed to do, and the tests will always be there. If the code stops doing it in the future the tests will fail, acting as a permanent, enforced documentation. This leads Grenning to bring up the concept of regression tests, which confirm that your new changes don’t modify legacy behavior. The suite of regression tests that you slowly build over time will make sure nothing is inadvertently broken. But as you write new tests, you’re also getting instant feedback that your new code is performing to specification.

My life as a programmer is much better with TDD.

James Grenning

TDD brings you back to the programming exercises you did when you first started learning. It is satisfying as it is to struggle through a problem and make your project do what you want. But it is so much more satisfying to see a big green bar that tells you everything is working, including everything you’ve done since the beginning of the project. Then you can play with your new features manually if you so desire.

There are some downsides to TDD. More code means more time and more to maintain. Sometimes you’ll have to change tests because what your code is doing also changes. Furthermore, TDD is an art in itself and must be learned, meaning you may need to break old habits of bad design to write code that is testable. I’m inclined to agree with Grenning that debugging a complex system is much more time consuming that these downsides.

It only took a couple weeks of clear thinking to realize I had overreacted when I uninstalled Android Studio. I learned to have a lot more patience and take the time to do things the proper way. I still forgo testing and TDD for small, personal projects, but the benefits of TDD greatly outweigh the downsides for any important project.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

A topic that caught my eye when looking over the syllabus for my CS-343 class was Code Smells, so I decided to delve deeper into the topic. I read a blog post titled “CODE SMELLS THAT ARE FOUND THE MOST” by Ekaterina Novoseltseva, which talks about commonly found design flaws in code and how to address them. Ekaterina goes through a list of those design flaws like the bloater which are code, methods, or classes that are too large or have grown too large making them difficult to work with. Another mentioned design flaw would be the change preventer, which as its name implies prevents change by making the coder change multiple places in order to fix/change one section of code. There are many more examples of code smells that are explained in the blog.
One of the code smells that stood out to me was long methods because for a while that was something I would do while coding and it made my code almost impossible to track and understand, as well as, made it hard to trouble shoot where my issues where when my code did not pass test classes. Having long methods made coding extremely difficult and created more problems than it did good. another code smell that really hit home was duplicate code, even though it is easy for me to just copy and paste the same code into multiple methods, it makes more sense to create a single method that can be used in multiple places. simplification of code is something that I have been working on because it makes coding a lot smoother and easier to adjust and make changes to in the future. The last code smell that really spoke to me was dead code which is code that is not being used. Too many times I find myself writing code that is too complicated or doesn’t work, and then commenting it out or saving it for future changes and usually forgetting about it which makes it all the more confusing for some one reading or looking at my code. learning more about code smells has given me the confidence and knowledge to avoid them in the future and to make simpler and cleaner code. Design of all things is meant to be efficient and useful to both the designer and the user, so to practice and understand good design a person must understand bad design as well.
Link to the Blog Referenced in this post: https://apiumhub.com/tech-blog-barcelona/code-smells/

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.