How to avoid bugs
I have often come across some developers who for some reason do not ever want to test what they have written. They write code, see if it compiles, check one or two scenarios and viola, expect it to work like magic! For some strange reason, the brain wiring of us developers is such that we trust our code completely, and feel that there are very remote chances of it going wrong.
Unfortunately, this does not happen too often, and most of us end up sitting late night in office fixing things they could have caught much earlier on, when there was sufficient time to clean the mess. If you are developing code and in all likelihood will also maintain it later, it makes a lot of sense to test things properly. even if you are planning to pass on the code to some other person, it will save both of you a lot of trouble if the code was well written and thoroughly tested. Here are some time tested techniques.
1. Think before you leap.
Sounds weird and bookish? However, a well planned code in all likelihood will also be well executed. Most of us try to rush to the code and make changes as soon as we sight a new feature or a bug report. However, this rush tends to make us forget the corner cases, those which almost often turn up in user testing. It helps to take a deep breath, stop yourself from changing the code immediately, and just imagine the kind of change and its impact on the flow and
2. Write comments before writing code.
A very basic tehcnique, this helps to develop clarity about the module one is planning to write. It does not take much effort either, and once the code is written and one goes back to the comments, one realizes the missed cases and the erroneous implementations. It also saves time during coding. One needs to try this to fully understand the power behind such a simple technique
3. Take a print and read your code.
Once the code is fully tested as per your satisfaction, take a print and read it at leisure. You will be surprised to find the number of doubts you get, or the soaring confidence you have at the well executed code. If taking a print is not comfortable, one can read it on the screen too, though personally I think one tends to miss out on things on the screen. If your team has group code reviews, its great, but if not, then you probably need ot take onus and read the code yourself.
4. Version control at logical points.
It helps a lot to check in code at regular intervals. Logical points help one achieve clarity of how the code is shaping up, what all is already implemented and what all features need to be put in. One can revert to an older version in case of an issue, and not lose the older working copy in case of an erroneous new feature.
5. Scan code for issues.
Once you get a bug, you can check the other similar cases and see if the same kind of bug is reappearing at other places. This technique helps you to understand yourself much better, you will be surprised to find that you probably missed out on some specification, or misunderstood it, or could not think of some particular scenarios. Any or all of this information helps you shape up as a much better coder in the long run.
I guess there are no magic mantras, the above techniques are all fundamental and time tested. Just hoping that having them in one place will help!
Unfortunately, this does not happen too often, and most of us end up sitting late night in office fixing things they could have caught much earlier on, when there was sufficient time to clean the mess. If you are developing code and in all likelihood will also maintain it later, it makes a lot of sense to test things properly. even if you are planning to pass on the code to some other person, it will save both of you a lot of trouble if the code was well written and thoroughly tested. Here are some time tested techniques.
1. Think before you leap.
Sounds weird and bookish? However, a well planned code in all likelihood will also be well executed. Most of us try to rush to the code and make changes as soon as we sight a new feature or a bug report. However, this rush tends to make us forget the corner cases, those which almost often turn up in user testing. It helps to take a deep breath, stop yourself from changing the code immediately, and just imagine the kind of change and its impact on the flow and
2. Write comments before writing code.
A very basic tehcnique, this helps to develop clarity about the module one is planning to write. It does not take much effort either, and once the code is written and one goes back to the comments, one realizes the missed cases and the erroneous implementations. It also saves time during coding. One needs to try this to fully understand the power behind such a simple technique
3. Take a print and read your code.
Once the code is fully tested as per your satisfaction, take a print and read it at leisure. You will be surprised to find the number of doubts you get, or the soaring confidence you have at the well executed code. If taking a print is not comfortable, one can read it on the screen too, though personally I think one tends to miss out on things on the screen. If your team has group code reviews, its great, but if not, then you probably need ot take onus and read the code yourself.
4. Version control at logical points.
It helps a lot to check in code at regular intervals. Logical points help one achieve clarity of how the code is shaping up, what all is already implemented and what all features need to be put in. One can revert to an older version in case of an issue, and not lose the older working copy in case of an erroneous new feature.
5. Scan code for issues.
Once you get a bug, you can check the other similar cases and see if the same kind of bug is reappearing at other places. This technique helps you to understand yourself much better, you will be surprised to find that you probably missed out on some specification, or misunderstood it, or could not think of some particular scenarios. Any or all of this information helps you shape up as a much better coder in the long run.
I guess there are no magic mantras, the above techniques are all fundamental and time tested. Just hoping that having them in one place will help!
posted by Sonal at 11:08 AM
