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

Popular posts from this blog

CI/CD Automation: How to wait for Helm deployment into Kubernetes cluster

 So I created this post because with Helm v3 , if you use --wait option and the timeout is reached and the deployment isn't successful, Helm marks the deployment as failed . The problem is that subsequent deployment (upgrade) that may contain the fix won't work as expected and it will end up in error like this: [some-name] has no deployed release   The only way to fix this is manual intervene and deleting the previous failed release. This is not only scary but also against the automation process. If we remove --wait option, Helm will mark the deployment as successful regardless. My solution to this that works nicely is as per below: Remove --wait option from helm deploy Use this command to retrieve the list of deployment for that namespace that you are deploying against: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}' You can use split to turn the comma separated list above into an array Then you can run mul...

Hibernate And Mapping enum to customized values

With Hibernate, enums can be easily mapped either by enum item name or the position of each item but what if you want to map it to a customized value? In my case, we have so many one-character long columns in our tables, representing flags, statuses etc. We have heaps of them. Writing UserTypes for each enum field is very boring and nasty job. As every where you see in internet, you need to keep a Map for each user-type in order to map those values to enum elements. So to avoid this, I ended up with something more clean, easy and more generic. Now imagine you have following enum: public enum PaymentFrequencyEnum { WEEKLY("WK"), FORTNIGHTLY("FN"), MONTHLY("MT"), QUARTERLY("QL"), YEARLY("YL"); private String value;     private PaymentFrequency(String value) { this.value = value; } } I've chosen two-letter code as value so that you understand m...

JSF or GWT?

I have worked with JSF for almost 4 years. First time when I had a chance to work with GWT, I was very excited. Like many Java developers I was like 'Wow I don't need to play with those bloody tags and elements and now it's pure Java code!!!'... I was so happy but my happiness didn't last very long. Programming is my passion. I hate writing codes that become a mess later and unfortunately this is what will eventually happen with GWT. The thing is you can't rely on reviews and features of a software or an API, in action everything goes different way. Specially when it comes to large scaled application and in an environement where everything is urgent and importnat... well, I think all software companies are the same in this regard... The fact is that in a team of developers not every one cares about best practices, design patterns and even if you have very experienced designer, solution architect etc, still you can't force the team to deve...