Hi everyone, I am Kien from Polaris team.

I still would like to share my experience from the point of view of a developer.

As a developer, what we want to do is to create flawlessly programs, which means programs we created have least bug as possible.
Certainly, bugs can not avoided. But we can decrease the numbers of bugs. There a lot of reasons for a bug reported: inefficient requirements, requirement misunderstanding, impotent SQA, and maybe the main reason is come from us, developers. Being a carelessly developer, we may have a lot of reasons to create potentially bugs: do not understand requirements, lack of communication, lack of teamwork spirits, do not write unit tests, do not perform tests…

And the following is what I do before I inform other team members that I 100% finished the coding so they can perform smoke test or joined test.

1st Step: Understand the requirements

Yes, certainly we must understand the requirements before we start to do anything. Without knowing what we will create fully, we could not create anything or what we will create would have tons of bugs or we have a lot of time to confirm requirements while we coding or we have to throw what we created to the trash bin >_<.

Key points:

– Understand every components of the screen given in the requirements.

– Also understand every lines of comments and texts in the requirements.

– Question yourself that it is logical to have a screen like that

– Imagine the background logic: how we can display a screen like that, what data we need to display, what we will process if a certain action is performed…

If there are things make you feel confused, do not be hesitated to confirm it to leader or bse. Make sure you fully understand every aspects of requirements before proceed to the next step.

2nd Step: Writing detailed designs(DDD)

I do not really like the way of writing detailed designs of Polaris team, or more precisely, the contents of DDD. Maybe many developers think that writing DDD is not necessary and not writing it would not be a problem if I understand requirements fully. However the DDD has lot of functions:

– It tell other members how you code to produce the function

– SQA will use it for their test cases

– It helps you code, and it helps you check what you did <– this kind of function is hard to do with current detail level of Septeni’s DDD format

Due to the fact that SQA will base on your DDD to write test cases, so in order to avoid bugs reported by SQAs, firstly, you must depends on your DDD while you coding.Imagine the flow of the process, write it like a pseudo code, write details as much as possible for the components of screen, you will find that you willing to open your DDD while you coding.

Since almost DDD is in Excel format, I like to change color of every line I coded to a specific color. It helps me know what I left and the overall progress.

After coding finished, I always do a re-check, and this time, I change the color of lines I checked to another color. (This re-check is necessary because while I coding, the coded line may be affected by other codes).

3rd Step: Write Code

Since I talk to much about DDD above, may be this part would be short. Because what I did is code follow the DDD. Open DDD while I open the IDE for coding. (It would be best if you have dual-monitor computer).

I know that Septeni like TDD but TDD is still hard for me to apply. Below is some of rules I follow when I code or review code:

– Never use an useless name for variables, functions, classes…

– Use exceptions instead of using error codes

– Catch every possible exceptions, do not rely totally on framework exception handler

– Write log for every errors. Good for debugging and maintenance. Be ware of logging level.

– Try to break down a function to be below of 200 line of code. Each function must do a specific task.

– Stay focus when process error cases, especially when working with web apis or databases.

– Also be aware of null cases, empty string cases, empty array cases. Null exception is probably most seen among potential exceptions.

4th Step: Write Unit Test

I am not a good unit test writer. However I found out that many people in Septeni wrote tests worse than me :).

Remember fulfill the requirement of code coverage is not more important than write tests for all possible inputs and check the outputs. If there is an if conditions, write test every check in that “if”.

For example, we have if (!str || str.length == 0) {}. For code coverage metrics, I can provide unit test will null input only. But it would be sufficient if you test with null and empty string and non-empty strings.

And also remember to test with bound values, especially working with numbers and dates. Checking the input integer is between 10 and 99. You should test with 9, 10, 11, 98, 99, 100 values (and also another random number like 76).

Writing test always helps me to find minor bugs before release. (Especially when I develop a new screen or function)

5th Step: Test

As I mentioned in 2nd step, I do a re-check what I code by using DDD. Maybe this work is a little similar to joined test or integration test but I guarantee that many of bugs can be found at this step. Do not rely on SQAs on finding bugs. Try to find it before you commit your source code.

This kind of tests also covers cross-browser tests. If your product is required to be compatible with two or more browsers, test with all of them.

6th Step: Refactor and Commit

Actually, the right sequence of 5th and 6th step is refactor -> test -> commit, because while we are refactoring, including changing logic block, breaking down functions, it could affected what we had tested, so re-test is needed. However, since dividing into too much steps is not a good idea, I combined refactor and commit into one :D.

Refactoring, include:

– Add comment for every classes, functions, global variables, long logic blocks

– Be sure to follow the Coding rules defined by the project or company

– Make classes and functions understandable and short. A too long class or function means you did not refactor it well.

– Remove codes for debugging just like print something to screen or console.

Actually, I strongly believe that the team should use the same IDE for development with the same configuration. And using same kind of tool like checking style of codes would even better. It reduce time of reviewing code for code-reviewer.

For Java development, I use those tools:

– Eclipse: NetBeans or IntelJ is okay. But please define the same IDE for the whole team.

– CheckStyle: Automatically warn you if you have a variable with wrong format name or you forget to comment your function. Using it to check whether you follow the coding rules or not. Define the rule of Checkstyle and use on the whole team.

– Formatter: It helps me save lots of time when I trying to make my code beautiful. Automatic indenting, or removing spaces

Before you commit, see the changes and make sure you know the meaning of every codes. Keeping the unknown meaning codes implies you don’t know what you are doing.

That’s all!

Maybe I just an all talk. Frankly, sometimes I omit some actions. But be aware that when a bug reported, it takes lots of time until it is closed. SQA must post it in Redmine, developer then confirm the bug, fix the bug, and then SQA re-test on real environments. So paying a little time for testing while coding will save you more time in the future.