This is the fourth part of a mini-series I have introduced in this blog.
In the previous parts, we have only talked about plans on how to do every bit there is for the target application. In this part, we talk about implementing everything that was planned.
Now would be the time to put the designs from previous steps into files that will later be used to produce the target application. There are several things to consider during program implementation:
Yes, there should be rules on how the source code should be created. This should be done so that if ever another developer would take over the chores of studying and modifying the source code, the time to do so would be less spent on trying to understand how the code was written and how its contents are organized.
If you’re a fan of console games, then you may be familiar with the “save game” feature that would let you pick up from where you left off, especially when a game would take lots of hours to several days in order to finish all stages. Some savvy gamers would also use the same feature to go back to the nearest convenient point in the game whenever they want to experiment with games that have nonlinear storylines — in case things get messed up within the game, they could just go back to where they think is a point where the player character has a lot of health or skill points.
This strategy can be applied to the source code being used in a development project, with the use of source code control systems like CVS, RCS, and Subversion. A situation that best illustrates the advantages mentioned is when you encounter a problem with your program and you’re having a difficult time tracing down the buggy part. If you have just ‘checked in’ the source code before doing the modification that you think caused a bug in your program, you can just discard the current fileset and retrieve the previous version from the source code control system server.
This is a touchy subject that I think still needs attention. Developers have their preferred editor. However, there are things that should be considered to maintain consistency in the source files that each editor creates. Issues like tab spacing, converting the tabs to spaces, text file format (DOS/Mac/Unix) being saved, and character encoding. There should be an agreed-upon standard, to make sure that when one file is created in one editor, it would appear just the same when opened in antother editor. Case in point: create a source code using vi, and then open it in notepad.
For projects with multiple developers, there should be a fixed schedule where the developers would upload their latest source codes into the repository of the source code control system. This would make sure that one member has the same set of codes as with the other members of the team.
For the developers, there are also several things to think about:
This is the one thing that separates the newbies from the experts. Newbies can produce working code, but the experts are the ones who create code that not only works efficiently, but also looks easy to read and understand. Code should be created so that when somebody looks at it, a better understanding of how it works and how it was designed can be seen.
As much as possible, resist the urge to deviate fom the original design. The possibility of other units being affected after any design modification in this part of the development process is very high, since at this point most developers concentrate on how the individual unit assigned to him or her is being implemented and not much on the others. However, if a design change is inevitable, care should be taken that the documentation written during the design stages should be updated first before doing the same with the source code.
Some people do, and some people don’t. However, it’s good practice to make sure that the code that was created is free from compile errors so that when these are used with other units, the time would be spent on just testing the codes.
When implementing software design nowadays, it is mandatory that extra time should be allotted for creating an accompanying set of codes that would be used to verify the functionality of the untis that were created. Use the checklist created in the previous step as a guideline for creating the test program.
That will be all there is for this step. Again if you have comments or questions, please leave a comment so that we can clarify things. Keep visiting this site for more updates on the series.