During development of software, debugging becomes easy when we have working code after each commit. O'Rielly's "must read" articles for programmers also recommend planning each commit well. This actually is a better way than unit testing, though is much the same in some cases. The advantage here is the developers are not only sure of the working of the newly added unit but also of its integration with the rest of the code.
To exemplify, I share the following screenshots. The screenshots are of an rtf file renderer. The folowing is the screenshot after foreground color implementation. Here the font size is rendedred double the required size. Also note the unnecesary space in between the letters 'm' and 'p' of the word "example". There are other similar cases too.
In the next commit, the font size problem is fixed, yet the problem of unnecessary space remains unsolved, though it doesn't seem to make much difference.
The above were the screenshots of successful additions to the software. However, in between these, there must be numerous trials that reveal error in implementation. The point is while attempting to get a particular task done and properly integrated reduces debugging load.
The process described above is typical in scripting languages like Python, Lisp, etc. Following these lines in languages like C isn't difficult either. Its just one task at a time. So you build the base first - an unpolished prototype of a prototype - add features to it and improve the base to integrate better with the added features, i.e. bottom up.
No comments:
Post a Comment