Unit testing has made my infinitely easier and it can make yours easier too. For the first couple years of my Computer Science education I did no unit testing whatsoever. My method for building a program was to write everything, and then start debugging. This is a terrible idea. If you've ever done this, you know that it just doesn't work well. Just a few small errors at the low level can make your higher level code unusable. These small errors mate with each other, creating weird problems at the high level. The program behaves in very odd unexplainable ways. At this point, it takes a long time to trace the error back to its source because you start at the high level problem, then have to check through a series of problems until you come to the original one. Wouldn't it just have been easier to write a test for your low level code in the first place? I have changed my poor coding practice ways. Now I write tests for each small component of my programs before using them at a high level. This way I know that my program has a solid foundation to stand on. You can implement this design process with a bunch of printf statements but there is a much easier way to do this. CxxTest is not difficult to use and all it requires is a C++ compiler. It is about as simple as #include'ing the test suite in your code and writing a bunch of assert statements where you want your tests to be. After doing this you can run your tests every time you make a minor change, and verify that the overall structure of your program has not changed. This way you can find a problem before it spirals out of control and creates some painful to fix problems.
Source control is of vital importance to a group of developers working on the same project, the same file, or maybe even the same few lines of code at times. In a scenario with no version control at all it is very easy to destroy the work of others. Imagine this: John and Joe are working on the same file at the same time. Joe doesn't think that an array will be an effective data structure for a heapsort so he begins to change it to a tree node representation. At the same time John is tracing an off by one error back to its source, using a debugger. After Joe has been remaking the algorithm for about 45 minutes, Joe finishes, saves, runs his test cases and breathes a sigh of relief. About two minutes late John locates the source of his problem, and changes an equal than or greater sign to an equals sign and then saves. Suddenly all of Joe's programming was for naught. Joe's new heapsort was overwritten by a slightly modified old one. This is why version control is of great importance. If they had been using a version control system like Subversion this mistake could easily have been avoided or rectified in a matter of seconds. Subversion would have noticed the conflict in the different codes submitted and asked for a resolution. In a slightly different scenario let us suppose that Joe's new heapsort algorithm didn't work at all. Either his fundamental idea was unrealistic to begin with or it just hasn't been executed properly at all. Then he has destroyed his old mostly working code in favor of new code that doesn't work at. He can either try and fix his current code, or try to remake the old code. Both cases will involve some amount of pain. With subversion he could simply roll back to the previous version with a simple command like "svn merge -r:10:9". This also simplifies experimenting with your code greatly. Sometimes you have to radically alter your code in a way that may or may not work. This is just a great big undo button for large portions of code. Previously I would have been reluctant to change great swathes of code but this way I know that
I can get back to a version that will absolutely work without fear, or making a big mess of my code with long commented out portions.
Working with a partner has both drawbacks and benefits although the benefits outweigh the drawbacks. When you work alone, you have those debugging moments everything looks completely fine and yet your code still does not work. You continue to stare at the code but it is no use and you're just wasting time. Then finally for some reason or another, your mistake hits you and it seems like the most obvious thing in the world. Moments like these tend to disappear when you have a partner. Simply having another pair of eyes on the code helps significantly cut down on the amount of trivial mistakes. This also works for seeing potential problems. Error checking will be better and there are more possibilities of input that could break your program. Another advantage of working with a partner is the diversity of ideas. Your partner might have a more efficient or more readable way of doing things. They can point out the fundamental flaws in your idea, or you can reach a creative medium between the potential strategies. The best part is you only have to write half the code (in the ideal situation). But there are disadvantages. If you are not careful about the way you store your code, you could potentially save over your partners work or vice versa. This can be mitigated using software like Subversion. Subversion has conflict resolution software, and other features to ensure you do not accidently destroy a few hours of work. Another problem is that the influx of ideas can prove a distraction when you have a deadline. A few key hours that could have been spent coding on a safe idea, could be frivolously lost on an idea that never really panned out, and had limited applicability. You also have to invest a certain amount in communication with your partner. If you're dividing the workload, what is who's responsibility, and if not then what times you can meet to code.
Blog Entry 1
One thing that I very much need to work on is my use of Software Development Tools. I've always used the sort of quick and dirty approach applications. I don't even know what a version control system is, so my knowledge in that area could definitely improve. In Linux I've always used geddit as my goto IDE, even though it is basically featureless, and when I SSH in I use nano. Nano is pretty awful, it takes all the tabs and replaces them with spaces. If you're writing a long program you have to use the directional keys to get from one end of the document to another. When you add up the time wasted simply navigating the document its quite a bit. I could probably improve the efficiency of my coding simply by learning how to use an IDE that isn't just a glorified text editor. In terms of debugging I've been a printf kinda man. I've used gdb on just one occasion and that was for the bomblab. I'm pretty sure I already forgot how to use it. This area is particularly appealing to me because I could significantly reduce the amount of time and trivial frustrations in my coding and focus on the things that actually matter.
Software Development Processes is another area I need to improve on. In that paper we had at the beginning of the class the author talked about the build it and fix it approach. This been my primary method for designing my programs. Sometimes I write some skeleton code first to get a feel for it, but generally I just dive in and let my ideas flaws pop up as they will. If I had some sort of structure to the way I planned my coding it would probably save me a lot of pain in the long run.
One of my strengths is Program Design. My software design is usually pretty modular, specific functions can be isolated and changed without having to find and change other pieces of the program (usually) and my comments always accurately describe the input, output, and what the function or class does. I generally don't have trouble adhering to a specific layout or style. My code is formatted correctly and very readable. It is almost always obvious what is going on, or if it isn't then my code is well documented. I do this because it makes my life a lot easier later if I have to go back and edit. If I need to debug there is a specific module of the application where I can isolate the problem. Making my code readable makes it way more pleasant to scan through visually and will just generally alleviate my headache at a later point. In my early days of programming everything was messy and debugging/editing them was pretty much the worst thing ever.