The link at the very bottom is an article focusing on a design philosophy YAGNI which is one of the topics we’re supposed to cover in class, though we haven’t gotten to it yet as of my writing this. The name is an acronym of “You Ain’t Gonna Need It” which is basically means if the situation doesn’t immediately call for something to be done, then don’t bother with it. The acronym’s meaning is also the main reason why I chose to write about this topic; it sounded funny to me. The article goes on to describe four “costs” that YAGNI mitigates. The first is the cost of build which is the time and effort spent on analyzing, programming, and testing something. The second is cost of delay which is the cost of pushing back other priorities in order to work on what is deemed more important. The third is cost of carry, the complexity that something brings to software and how that modifying and debugging more difficult. And the last is cost of repair which is self-explanatory. By only working on what is immediately important, the chances of wasting time or changing the program are reduced significantly.

What I find interesting about YAGNI is that in a way, it’s telling people to wing it. The biggest reason for that is because in everyday life, sometimes plans change because of unforeseen circumstances. Let’s take for example someone meticulously planning out a program while taking multiple scenarios into consideration and designing different components to compensate. But it later turns out that many of these scenarios are either unlikely or are taken care of by other things outside of the program that this person didn’t even know about. That in turn causes cost of carry because of all the components complicating the core program, cost of build from the time and effort wasted on designing and implementing these components. These are a lot of headaches that are solved by just being lazy and that’s kind of funny to me.

Something else I noticed is that YAGNI is a really simple design philosophy, to the point where it isn’t strictly constrained to software design. Another example I’ll bring up is how when I was younger, I would waste time writing essays by agonizing over small minute details. And a piece of advice I would often get is to write out my first draft no matter how horrible and worry about fixing the details when the time comes. That isn’t to say that drafting out an outline isn’t important; this applies both to essay writing and software design. The truth is that there should be a balance between YAGNI and other design principles which the article does acknowledge even though it does downplay it.

Link: https://martinfowler.com/bliki/Yagni.html

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

Hello everyone and welcome back.

 This week I will be exploring three of the five design principles of OOP; Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov’ Substituion Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP).

My first introduction to these principles was in reading “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin. Prior to learning these concepts, my code was messy and not easily modified. I used to put way too many methods in classes, and my child classes were not fully compatible with the parent classes. I chose this topic because we all benefit when our code is adaptable, clear-cut and easy to maintain. I chose this blog because the author presents the information in a very direct format with great examples.

The purpose of these design principles is to make our code easier to maintain, change and understand. As software engineers, a lot of the code most of us will be working on will be code that others have written. There will be others who will be maintaining our code when we are no longer working on it. When we follow these design principles, not only do we improve our coding skills, but we help those who maintain the code we have written.

Single Responsibility Principle (SRP) means that a class should have only one purpose/task that it is responsible for. This makes code more maintainable by making software more comprehensible for future changes to be made. If a single class has multiple responsibilities, editing in the future will be more complicated because we will have to make additional changes to the classes that are dependent on it. You will have to update and recompile dependent classes that are not directly related to the change you needed to make.

Open-Closed Principle (OCP) means functions, classes and modules should be written such that others can add to them but not change the core elements. When we use this principle our code, our software will give less errors when requirements change. This makes our code more robust and reusable.

Liskov’s Substitution Principle states that every dependent class should be substitutable for their parent class without breaking functionality. Our validation rules on input parameters in subclasses should not be stricter than the input parameters on the parent. Using this principle increases maintainability of our software by making our class hierarchies easier to understand.

Through utilizing these design principles, I will be a better software engineer. I am more aware of ways to improve the legibility, and modifiability of my code. These design principles will help me stay away from poor coding practice.

Blog of Inspiration:

https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea#.xq7a6fvtk

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

For this week’s post in the coding journey blog, we are going to talk about a principle in software coding knows as dry. I chose this topic for this specific week because it felt relevant to the classwork we did this past week with super classes, abstract classes and interfaces.

What dry means is don’t repeat yourself and this concept is very important for developing software. The actual principle is represented as “Every piece of knowledge or logic must have a single, unambiguous representation within a system.” Now take for example the classwork we were doing, and how there was a method in the superclass that we decided all the subclasses would also include through inheritance. Now in the subclasses, if we wanted that method to do a different version of the method such as fly or quack, then we would have to alter each and every subclass. Even if a subclass does not have the fly or quack method, we would have to add the method and have the code do nothing. Just by talking about this you can see how redundant this starts to become. Now you may be able to get by with this repetition if you’re working on a small project and don’t have much to check for. However, when it comes to larger projects this will certainly turn into a never ending nightmare. Your code breaks and you have to go through all this different code which is similar and figure out what is off. This just seems like a waste of time and effort. This is why the common notion is to use the principle of don’t repeat yourself which has the goal of reducing repetition of the same software over and over again.

The big problem with repeated code over time is that it will become very hard to maintain. If over time, there comes a big change to the code and the logic changes, then it will become a headache. All the places where the previous logic was used, needs to be altered and the big thing that will be wasted is time. If you want to create quality code, then you will also have to use quality time. It is thereby better from the get go to design code to not repeat the same unnecessary methods and logic in multiple places.

To put this into perspective on a personal level, in the past I most certainly used repetitive code and wasted a lot of time. It may have seemed like the easier option sometimes, but as I dove deeper into my projects it became more difficult to figure out the solution for bugs and tracing the code for error. In the future, I know it is the best option to optimize the best way for the code to work without repetition in order to help myself and others down the line.

To read up on more sources, check out these links here: https://medium.com/code-thoughts/dont-repeat-yourself-caa413910753

https://dzone.com/articles/software-design-principles-dry-and-kiss#:~:text=DRY%20stand%20for%20%22Don’t,unambiguous%20representation%20within%20a%20system.%22

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

After the class activity on smells, I was interested in knowing more about it and how it relates to programming. The term was quite interesting, so I chose this topic because I wanted to know more. After several searches, I finally settled on this blog that talks about code smells and makes it easy to understand.

In this blog, I like the fact that it relates code smells to the everyday smell that we know, typically body odor. Initially I was thinking of code smell as a bug but this blog made it clear that it isn’t a bug. Blog talks about the downside of having code smells which are causing technical debt and affecting the maintainability of software system. It also gives some links to some series that explains more about code smells, giving examples, code snippets and how to identify and solve smells in a code. It talks about various code smells which are Method-level, Class-level and General-level code smells. Each type of code smells mentioned explains and give an overview/points on what to look out for in codes/programs to identify a specific kind of code smell. This blog also talks about some stereotypes of code smells that I found interesting and relevant.  

In this blog, I learned that code smell is a piece of code that we perceive as incorrect but do not fix right away. That being said, code smells in software programs will produce output but may affect the quality of the program if not taken care of.

In method-level code smell, I learned that there are certain things that one must check in methods to identify smells. These include the method not being used, taking too many parameters, doing too many or little things, having too many branches or loops. I always thought that methods can have as much parameters as it can but little did I know that too many parameters in a method could affect a software system and needs to be corrected. In the future I will not include methods that I do not use in my program.

I learned in Class-level code smells that the name of a class and programming interface should reflect its purpose. Also, when a class does too much or too little work, class unnecessarily exposes its internal details, inherits a base class but only some of its inherited behavior is needed, design of a class is overly complex are indications of code smells.

As I was reading through the series in this blog, I found very educative term which is factory method. I learned that factory method is a method, typically static, that returns an instance of a class and uses a constructor publicly or private. When too much work is required to get new instances when using constructors, it is always encouraged to resort to factory methods, although there are other cases where one could use factory methods.

I hope this blog is helpful to others as well.

https://blog.jetbrains.com/dotnet/2018/06/18/sharpen-sense-code-smell/

From the blog CS@Worcester – GreenApple by afua3254 and used with permission of the author. All other rights reserved by the author.

Today, I will be talking about an article titled, “MongoDB : an Introduction” by Harshit Gupta on Geeks-for-Geeks.com. This article explains what MongoDB is in a simple format by comparing it to relational databases. He explains that MongoDB is a NoSQL database meaning it is non-relational. Instead of storing data in a tabular format such as SQL, it stores data in its document model which is much more flexible. This makes it similar to a JSON format (called BSON which stands for Binary JSON). When dealing with big data, it is a much better choice to use MongoDB instead of a relational database because it is horizontally flexible. This means that if the demands of the database grows, we can add more servers so that it can handle the change. While adding a new column to a RDBMS requires replanning of the schema, adding new fields to a NoSQL database is easy because it is schema-less. Another major feature is that MongoDB is a distributed database meaning multiple copies of data is stored across multiple servers making data recovery fast and reliable. The article provides easy to read bullet points on the features of MongoDB, when to use it, and also the differences between MongoDB and RDBMS. It also goes over the languages it supports, how to install it, and provides a list of major companies using it.
The reason I selected this source is because Geeks-for-Geeks has always been a trusted website that I will go to when having problems in programming or with topics in class. They always provide a well thought out, simple explanation for topics that seem confusing in a textbook. While reviews for Geeks-for-Geeks are mixed, it has always been reliable for me and I have never had any problems with it. For basic topics at least, it has been very accurate. The content in this article held up with everything I have learned about MongoDB already, and also, matched up with what other writers said about it.
I chose this topic/article because I thought it would be good for anyone in class who does not yet know what MongoDB is and would like to read up on it. In this course, we will be using MongoDB for our final project to store data so we will be using it in the future. I started learning about MongoDB with this article as a good introduction then took it to more concrete and informative websites to learn about it further. MongoDB is good to learn if you will handling large amounts of data in the future.

Source: https://www.geeksforgeeks.org/mongodb-an-introduction/

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