This article was originally posted by Javin Paul at Javarevisited.
We often here the term “production quality code”, some times in interview where interviewee asked to write production quality code for a particular function, some time discussion between developers and programmers and some time during code review. I know most of you familiar with term but for those who wonder what is production quality code in simple terms its code which can bear the test of time in production environment.
We all develop code in development, than test in QA and finally it gets released in production. But there are lot of difference between test and prod and if you have not coded taking prod environment in mind most likely code will fail in prod or result in exceptions. So what makes production environment different than development environment? Here are few things which I noted:
1) Production is all about load which will expose concurrency issues, load issues, memory and CPU issues.
2) You will get a lot many scenarios in production that you might have thought in development. If think through process is not applied than most likely those scenario has not handled in production.
3) Different data input or incorrect data, one of classic problems in production is the data which gets input to your program, be it from upstream system or any other place you will get all sort of data and if your program doesn’t handle those very likely it will suffer.
4) Boundary conditions, this is some what related to above point data and scenarios but most of the boundary condition e.g. null, empty etc exposed in production.
So if a code is written all these things and potentially domain specific things and can sustain test of production than it called a production quality code and believe me it takes a lot of experience, skill and think through process to write production quality code not just in first time even after two or three iteration but as a developer we should always strive for writing production quality code in first attempt.
Now let’s see how we can do that, what are the things we should keep in mind:
1) Get your requirements right, understand the problem , talk to user or business person as much as possible this will help you to find different scenario as early as possible. Many times business or user not tell you everything its not there fault but it doesn’t come in mind right through. So if you are frequently speaking, discussing and presenting solution to them most likely they will ask questions, give feedback which eventually expose more scenario and subtle details. Here experience plays an important role. More experience or domain knowledge you, much better code you will write.
2) Think through, Think through and Think through. There is no substitute of this, it is more of a skill and art than science but you will get hold of this when you get more experience. For example if user says that you need replay capability in your program. You should be able to think of all possible scenarios where you need to replay and what could be required for that, what would be side effect of that. Does replay would be requested, what if the requesting system went down again, will you be able to replay etc.
3) Boundary condition, always think that you will get bad input , you will get null or empty, small or very large numbers, function may get called at wrong time etc. You can get rid of this by writing unit test for each boundary condition.
4) Concurrency, this is is the major culprit and big problem which exposes itself in production when due to load multiple thread gets triggered and access your program concurrently. With high speed low latency electronic trading system and with many other java system where its requirement to have a concurrent application this can only be addressed by proper design, if you get the design right you will safe other wise you will need to bear the pain of redesigning or rewriting code. You can also expose concurrency issue by doing load testing in early QA cycles.
5) Exception handling, this is by far most important characteristic of production quality code, it must be able to handle exceptional scenario in clear cut predefined way. Whole program should never be crashed due to one single bad input or scenario.
6) Recoverable, code should be able to recover itself in case of premature closing or crash.
Though these are just some points which I am able to thought, there are lots more and it’s a constant process of improving yourself and I always strive for this. Please share how you guys write production quality code, what are things you guys keep in mind, what questions you guys ask to yourself and to user?
* The views expressed in this article are those of the author and do not necessarily represent the views of, and should not be attributed to, Jelastic or its technology and distribution partners.