What this blog is about
See the diagram below for a quick overview.
Figure 1 What this blog is about
This blog is for readers who are interested in learning good programming technique. To learn basic programming, please refer to other websites. Here we assume that you already know the syntax and semantics of the language.
You will walk through a working example of a program. The program will ultimately have all features that can be listed as good OOP principles and will use the GOF design patterns, where appropriate. The initial version of the program will have quality issues. These issues will be resolved and the programming style improved, as we advance in our journey.
So what is good programming? Like in all other things in life, good and bad are relative; we have to learn to discern them. Of course bad programming is easy to recognizeJ. But good programming is not always so easy to recognize or learn. Hopefully this blog will help you in your journey.
Let us take an example which can show us why good programming can be fuzzy to define: Suppose you see a program that conforms to the SOLID object oriented programming principles and implements the relevant Design Patterns. All the code reviewers are happy and they gave the go ahead. There are enough test cases and they all pass. But what if the program is relatively slow and runs at 50% of the required performance?
We can never deploy such a program in production. All the goodness that has been incorporated in the code has academic value only. Now what? There is no need to throw away the code. We have to refactor the code to improve its performance. Poor performance is normally due to poor usage of data structures, inefficient memory utilization and slow algorithms.
In this context, I would like to introduce another term: Technical debt. Debt is when we owe something to someone. The problem with debt is that it tends to pile up over time. And then, the whole is bigger than the parts L. Technical debt refers to the weaknesses(big or small) that we intentionally or unintentionally insert into our code. These weaknesses get into our code due to project pressures or our lack of knowledge. Writing bad code helps us finish things faster. But it is a short term saving of time. In the longer term, such weakness(or debt) takes much longer to fix than the original time we save. Thus by saving some time now, using technical debt, we are borrowing a lot from those who will be maintaining this code later. Most probably when such debt “comes out”, it has been long enough in production, and it is someone else who is maintaining the code. They will take much longer to identify weakness inserted by the original developer. Thus in the long run, technical debt imposes heavy costs on the project owner.
Figure 2 Technical Debt: Borrowing from the future
In this blog, we will try to identify technical debt in our code, and improve upon it.
Presentation style: Conversing student and teacher
This blog is in the form of a conversation. Those who do not want to look at the conversation can see the code at github
directly. But I encourage you to read the conversation. Reading the conversation makes learning much easier. Laziness to read is one of the main causes of technical debt. I have seen this from my experience of reviewing code.
The conversation is between two individuals: the student and the teacher. The traditional way to teach is that the teacher dishes out knowledge and the student eagerly takes it in. But such a teacher-teaches-and-student-learns style gets boring after some time. So I have taken a different approach: the role of the teacher and the student are exchanged throughout the conversation. The teacher doesn’t know everything, as is normally the case. When such a situation arises, the teacher starts asking questions to the student. The student now has to find answers and “teach the teacher”J.
Figure 3 Exchanging the roles of student and teacher
Object Oriented Programming
The principles for class design and package design
The Gang of Four Design patterns
- Article by Martin Fowler
The Game of Life cellular automation