Skip to main content

Be A Good Developer - Part 1

Many developers try to learn and implement design patterns and object-oriented principles but most of the time they fail. Many only know those principals but they don't know how to use them or they don't know what they are for.

However, there is one principle that can help you from drowning. That is called Simplicity!


Simplicity doesn't mean you do the first approach that comes to your mind. That's probably the simplest approach though!

Simplicity means that you design a component and write the code in such a way that:
  • Looking at the code, anyone can tell what it's doing
  • Maintaining the code is easy and can be changed easily if needed
  • Debugging is easy and you don't need a million of break-points in order to find the bug. 
  • Writing unit test is easy and simple too.
  • The call-hierarchy of the methods in your code is not infinite!
  • If a part is broken and you have to fix it, you don't need to fix everything else.

To make your code/component simple, always think about a future developer who wants to debug the code to fix an issue or tries to understand the logic you have implemented. Now see how easy or difficult will be for them to understand the logic or the component that you are creating. If that's difficult to understand then there must be some unnecessary complexity in there.

If you need to add a little bit complexity in order to make the other part simple, that's fine but don't forget to put comments and explain what is happening in there. Comments in all programming languages are for this purpose!

The saying of what goes around comes around, is also true in software development and often the same developer has to deal with that component later on, whether enhancing it or fixing a bug.

I've seen many developers that they simply say "who cares about the future and what is going to happen to the application?"; or some say "I don't have time to think about a good design I need to finish it". 

But this won't take the developer's time nor is it difficult to think about it.

In fact, the time you spend designing the component saves you in time you spend coding and testing. Bear in mind that you also get less or zero bugs so that means peace of mind and confidence in your job.

If this becomes your habit, it soon becomes part of your coding personality and you will do it faster and more efficiently.


When you think about the simplicity in designing your component, you may even end up implementing a pattern that is already defined in software development design patterns without even knowing about it. After all, those patterns are just a bunch of approaches for solving problems in software development.

It's like a torch that leads you to the right path. You don't need to worry about decoupling or cohesion because they both will bloom in front of your eyes when you use this torch.
Today, software development is really different compare to say 20 years ago. Companies create large-scale applications with millions of lines of codes and hundreds of developers are involved. The developers come and go and new people take over. Then suddenly there is new technology and these companies have no choice other than transforming their product to the latest technologies and frameworks.

Simple design not only saves the developers time and their pressure but also the cost of maintaining and transforming the application.






  

Comments