The book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye gives great solutions/patterns for problems often faced by software developers, mainly apprentices or beginners of the craft. I have enjoyed reading up to where I have gotten so far (Chapter 1 plus 2-6 introductions) and it has taught as well as clarified many ideas and methods. One thing I have never thought of is how your first language will affect how you will think and learn other languages in the future. While this may be the case, the more diverse knowledge you have, the more you will improve upon this fact. For example (given by the book), people who are more comfortable with object-oriented languages should explore functional languages. This will broaden your understanding and problem solving. Another pattern I found interesting was the Be The Worst pattern. This discusses your environment and its relation to your growth. Being on a team where you are the best or most skilled does not give you much room or motivation to improve as you will not be learning from your peers. It suggests keeping yourself in an environment/team where you are the least skilled. This forces you to catch up to your teammates so that you don’t hold them back as well as forces the habits, ideas, and information of your higher skilled teammates upon you. A few patterns that addressed things I already “knew” but clarified the process at which I should take are Expand Your Bandwidth and Reading List. If you want to be a software developer then you should already know that you will be constantly learning. Expand Your Bandwidth gives solutions on how to learn more than what your job teaches you. It gives examples such as joining online academic courses, following influential developers on social media, contacting authors and more. This gives you a starting point from which you can come up with your own ways of learning or just to boost you in the right direction. The other pattern, Reading List, gives great methods on organizing your book backlog. The first suggestion is to not only keep a list of books you wish to read but the ones that you have read as well. This allows you to keep track of the books you’ve read from which you can review and find gaps or trends in your learning. This can direct you/help decide what you should read next. The pattern also suggests that you keep your book list as a priority queue. If you find a book on a topic that would be more useful or has a higher urgency then put it at the top of the list. If the bottom of the list gets to the point where you will probably never read the books in those spots then thats okay because it clearly is not a priority. I like the way this book structures these patterns too. The authors organize these patterns into Context, Problem, Solution and Action. This makes it easier to understand rather than if they were just put into normal paragraphs.

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.

Throughout this semester, I will be reviewing several different apprenticeship patterns from the first six chapters of our in class textbook. For my very first post, I decided to review the first pattern covered which was “Your First Language.” For many of my friends and classmates (including myself), Java was the first language learned. When we are first starting out learning programming, the book tells us that it is incredibly valuable to master our first language or two rather than try to learn a bunch of different languages at once. I am a firm believer in this notion as well simply because, with my knowledge in Java, I am able to translate to other languages fairly easily. The book explains that trying to learn all the languages instead of one for when a programmer is just starting out is not ideal mainly because it will end up causing more confusion than learning. If I am great at my first language, it is generally not too difficult to solve a problem in that language and then translate it to a new language after the fact. A great quote the book uses to describe this is by Alfred North Whitehead, and it reads, “by relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.” It definitely is a bit concerning to me when I see job applications stating I need to know certain languages or programs that use specific languages, but my original background in Java has proven to be extremely helpful in learning how to use those other languages. All the work I put into learning Java has helped me with my understanding of all languages, and for the most part, I just end up needing to teach myself the slight syntax differences between them all. This portion of the textbook spoke to me strongly because I have often thought about what would have happened if I had learned a different language for my first language. I see now that it most likely would not have changed anything, and that makes me happy!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch 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.