QUALITY. How do you measure quality? Generally speaking quality is an intangible thing, however it is not invisible. Quality is the thing that makes Apple products different from rest of the world. Quality is the thing because of which some of Japanese and German brands enjoy premium over their counterparts.
The same quality can be applied when we work with any kind of software development. In today’s world where outsourcing is another word for software development, people are less concerned with quality and more involved in just head counting. At the end it impacts both customer and service provider.
So, how do you plan to bring quality to software development? By employing CMM, Agile, RUP etc. No, they are all ways to manage project delivery. By employing any one of them will not improve the quality of software. To improve the software quality we will have to first accept that it takes time to get it right. Here I will touch upon some basic things which if you understand and try to implement in your day to day working, you will see your code quality going upwards.
First set of design principles is called S.O.L.I.D. principles. These are five different rules and if you follow them, you certainly will be a step ahead in code quality. I am reiterating them here so that even if you don’t follow the links, it somehow sticks to you.
|SRP||The Single Responsibility Principle||A class should have one, and only one, reason to change.|
|OCP||The Open Closed Principle||You should be able to extend a classes behavior, without modifying it|
|LSP||The Liskov Substitution Principle||Derived classes must be substitutable for their base classes.|
|DIP||The Dependency Inversion Principle||Depend on abstractions, not on concretions.|
|ISP||The Interface Segregation Principle||Make fine grained interfaces that are client specific.|
Recently I was reading another architecture related book that I thought every developer and budding architects should read. It is Microsoft’s Application Architecture Guide V2.
Another thing is that every developer should start familiarizing themselves with design patterns. Sooner or later they will realize that understanding design patterns makes them a better developer. I am not advocating that you need to be master of design patterns but you need to know few of them. Head First Design Pattern is good book to start with.
I believe every small step towards code quality is a big step towards customer satisfaction and meeting business goals. There are many more such practices which can make you a better developer and make your customer happy. I might discuss those things in future.