Here are some practical tips to make
your Java application more maintainable. Always remember, maintenance cost is
much higher than development cost and it's easy to give a solution but it's
equally difficult to give a maintainable solution i.e. something which can
withstand the test of time.
Before going to explains these 10 tips which can make your Java application more maintainable and easy to support, let me tell you that I have personally made a lot of these mistakes myself. It requires a great deal of discipline, hard work, and to be vigilant about writing quality code. Sometimes you have to push back even to your team lead or managers bringing the points like support, which is often overlooked.
Before going to explains these 10 tips which can make your Java application more maintainable and easy to support, let me tell you that I have personally made a lot of these mistakes myself. It requires a great deal of discipline, hard work, and to be vigilant about writing quality code. Sometimes you have to push back even to your team lead or managers bringing the points like support, which is often overlooked.
Don't swallow exceptions
Please avoid swallowing the exceptions. The stack trace is the most valuable troubleshooting information. In the production system where the priority is to bring the system up and then find the root cause, these exceptions are gold, without them, you will never be able to find what happened with your application at that moment. On the other hand, please don’t print the stack trace multiple times. Printing a stack trace is a resource intensive process and should be controlled i.e. you print more information while running on DEBUG or INFO mode and only print essential information while running in PRODUCTION mode.
Avoid excessive logging
This tip is closely related to the first one and at first it may look contradictory but in reality, it's not, in fact, they both compliment each other. When you run the Java application in your development environment (PC), nobody cares what’s the logging level you have. Go ‘DEBUG’ or ‘ALL’ if you please. But when it goes to production (or other higher environments e.g. QA or UAT ), limit your logging to ‘INFO’ or ‘ERROR’. Excessive logging has 3 major impacts:
1. It puts unnecessary load on the Application. I’ve seen throughput of application is reduced to half due to excessive logging.
2. It can fill up the file system very quickly and that can create issues for your application and other applications hosted on the same server. This is a serious problem especially if you are co-hosted with some other application. Do you know what will happen when root directory of certain flavors of Unix system fills up? - that’s right. No one can login into the host.
3. Troubleshooting will be painful, like looking for a needle in a haystack (if the poor support guy can ever get the log file to open).
Don't Forget to Close Database Connections
This is one of the most common reasons for production issues in the last decade, but thankfully with modern frameworks and library, this issue is actually slowly disappearing (as the framework takes care of opening/closing connections). However, make sure you always ‘close’ the database connection so that it is released back to the pool.
Don't underestimate production load
If you are an experienced Java developer you would have noticed that most of the issues are exposed in the production environment rather than in UAT or QA environment, especially concurrency related issues? Do you know why? because of production load.
You might have heard developer talking to support personnel that ‘It works fine in my development environment. But when it went to production, it crashed’.
Yes, it is the job of the load testing team to test your application with the production like load. But that does not mean that as a developer you write code that does not scale well. For example, it works fine for 1 user, but what happens when there are 500 users online simultaneously.
If you are an experienced Java developer you would have noticed that most of the issues are exposed in the production environment rather than in UAT or QA environment, especially concurrency related issues? Do you know why? because of production load.
You might have heard developer talking to support personnel that ‘It works fine in my development environment. But when it went to production, it crashed’.
Yes, it is the job of the load testing team to test your application with the production like load. But that does not mean that as a developer you write code that does not scale well. For example, it works fine for 1 user, but what happens when there are 500 users online simultaneously.
Avoid loading large result sets from Database
This is one of the common mistakes made by beginners and intermediate Java programmers who don't know about paging or pagination. You simply cannot load every record e.g. order or trade from database in one call. In some cases, obviously, you will run out of memory and it is also a waste of network bandwidth, CPU and memory as the user might not need all of those data.
Avoid hard coding Configuration
Parameters
You might have heard this tip several times but you would be surprised if you look at the code written by many professional software engineers and programmers. There is hardly a code where something is not hard-coded but hard-coding configuration values like URLs, directory locations, username/passwords, cache sizes, log levels etc in the code results in hard to maintain Java applications.
You might have heard this tip several times but you would be surprised if you look at the code written by many professional software engineers and programmers. There is hardly a code where something is not hard-coded but hard-coding configuration values like URLs, directory locations, username/passwords, cache sizes, log levels etc in the code results in hard to maintain Java applications.
Avoid packing multiple versions of same JAR files
Packaging utility jar files in several places, especially various versions of the same utility jar in various locations is the cause of many production issues.
You must have a clean build and versioning processing, especially for internal applications. Consider using Maven for dependency management, it makes life a lot easier than keeping versioned JAR files in the lib folder.
No comments:
Post a Comment