Topic: Achieving good quality code

Message

   How we achieve this:

1.
The two major tools we have to make sure the code works are testing and
code reviews. So, the code help you to review it and to test it. How to
do it is a topic for a much longer discussion, but to help you review
it it should be readable, with as simple logic as possible, with
comments where they should be and have many other charactertics. How to
write a code to help you test it might me even more complicated. One,
very useful tool to do it is to plan some of the tests in advance
(before or during the writing of the code). Then during the writing of
the code, you should look at your plan and always think "how can I test
it as easily as possible". Sometimes the answer to this question will
affect the code.

Writing the code to be testing and code-review
friendly is not enough. You should actually have it tested and
reviewed, fix the important code-review issues and testing issues and
only then the code can be defined as "working" in it's context (if
you're writing a single component it will be working as a stand-alone
part but not necessarily will work as part of the big system).

2.
To make the code easily changable there are many techniques. The
factors include the quality of the design and the coding. Some of the
techniques are separating abstraction from implementation, setting
clear and well-defined responsibilities, putting as much as possible
into the data rather than into the code and much much much more. This
too is a very complex skill.
To make sure that the code works after
you've changed him, the most common technique is to create automated
and wasy to run tests. Thus, you can run the tests on the changed code
(and to update them according to the changes) and make sure that all
the tests still pass. What is important is to make the tests as
non-fragile as possible (which is also bery hard), so that not every
little change will cause many of them to fail (not becuase of a bug,
but because some assumption of the tests has changed).
As for
reviews - if the change is not very big, it is recommended to review
the "delta" or differences from the previous reviewed version only. If
there were many small changes over some period of time, it is also
recommended to do a complete review once in a while.

I know that it helps very little, but it is the basics of "good code".

Author	Message
vidhya Senior Member Joined: 24Mar2007 Online Status: Offline Posts: 114	Topic: Achieving good quality code Posted: 28Mar2007 at 4:08am
	How we achieve this: 1. The two major tools we have to make sure the code works are testing and code reviews. So, the code help you to review it and to test it. How to do it is a topic for a much longer discussion, but to help you review it it should be readable, with as simple logic as possible, with comments where they should be and have many other charactertics. How to write a code to help you test it might me even more complicated. One, very useful tool to do it is to plan some of the tests in advance (before or during the writing of the code). Then during the writing of the code, you should look at your plan and always think "how can I test it as easily as possible". Sometimes the answer to this question will affect the code. Writing the code to be testing and code-review friendly is not enough. You should actually have it tested and reviewed, fix the important code-review issues and testing issues and only then the code can be defined as "working" in it's context (if you're writing a single component it will be working as a stand-alone part but not necessarily will work as part of the big system). 2. To make the code easily changable there are many techniques. The factors include the quality of the design and the coding. Some of the techniques are separating abstraction from implementation, setting clear and well-defined responsibilities, putting as much as possible into the data rather than into the code and much much much more. This too is a very complex skill. To make sure that the code works after you've changed him, the most common technique is to create automated and wasy to run tests. Thus, you can run the tests on the changed code (and to update them according to the changes) and make sure that all the tests still pass. What is important is to make the tests as non-fragile as possible (which is also bery hard), so that not every little change will cause many of them to fail (not becuase of a bug, but because some assumption of the tests has changed). As for reviews - if the change is not very big, it is recommended to review the "delta" or differences from the previous reviewed version only. If there were many small changes over some period of time, it is also recommended to do a complete review once in a while. I know that it helps very little, but it is the basics of "good code".
	MBA Examination papers Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Quality Assurance @ OneStopTesting : Quality Methodologies / Streams @ OneStopTesting