Thursday, November 17, 2011

Want to become a good developer

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.

If you want to know more about SOLID, you can follow aforementioned links or LosTechies have drafted a very good book on S.O.L.I.D.

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.

1 comment:

nilesh said...

Nice post Pradeep. It is sad that even after so many years and so much material being available freely on the net some of the most experienced developerd don't understand the "S" of Solid. Just to set the context I have seen pieces of code with classes containing more than 1000-2000 lines of code. Worst was a case where a single method was written with more than 1700 LOC in it.