This blog will contain posts for each of the various writing assignments for Computer Science 3081W. This is the first post, which will be my person reaction to the first iteration of our semester-long project. I will look at the inner workings of my team's process, discuss the pros and cons of working with a partner, and discuss what will be done for future iterations.
My partner and I decided to split the work between the files. I wrote the token matcher, and he wrote the test cases. We decided to split the work this way because we learned in lab that if two people edit the same line, you can only easily keep one copy without erasing someone's work. We had a base to start with from our labs, and so initially the project went smoothly. My partner wrote test cases, and I wrote regular expressions for each of the token types we needed to cover, as pre-defined in the header file. We decided to make a class to get the entire token, as it would contain all the information needed, including the expression itself and the type. In general, writing code separately, taking one file each worked quite well. It allowed both myself and my partner the opportunity to work side by side without any risk of conflicting lines of code. It also allowed us to update our code often without worrying about overwriting changes to our file. The major drawback we discovered was when we started to run our test cases. We discovered that there were slight differences between how we'd written regular expressions compared to how the test cases interpreted them. As an example, there was a misunderstanding between string constants in the test case and in the scanner getToken method. Other than that small issue, we didn't have any other real issues with our process of splitting work and coding. Working with a partner on a programming assignment leads to many of the same challenges of other group projects. My partner and I have worked together before, and so the prior experience allowed us to get away from many of the usual problems, such as lack of communication and adjusting to the others work style. Due to the fact that I've worked with him before, working in conjunction with him was just as easy, or perhaps easier, than working alone. I have worked with other partners in other programming classes before (At another school) that were much harder to work with. At the time, that particular person overwrote our main project file an average of 5 with code that didn't work, and we didn't have Subversion to load a previous save. In some instances, working with a partner can be fantastic, where you both can work together effectively and play off the others strengths. The most important thing you can do with your partner is figure out what each one is good at. Does one person know how to write C code with ease, while the other struggles? Perhaps one of you has experience writing lexers before, while the other has experience writing test cases. Whatever those strengths are, knowing what strengths you and your partner possess can make writing code together much easier.
The biggest factor working against us in this iteration was time. The first week my partner and I spent trying to find a way to get Subversion to work in an IDE in windows, so we could utilize syntax error finding, as neither of us had written in C or C++ before. We eventually got Eclipse to work, but even then it caused a small number of problems, such as crashing (For my partner), and not committing even though it said it did (For myself). I feel that in the future being able to start earlier, as well as having a better grasp of C++ will ultimately yield a much stronger performance in iteration two than my previous effort in one.
I think in the future separating the project into distinct sections, and each person tackling one of those sections will continue to yield the best possible results. We will most likely continue to develop code alongside our tests, as it resulted in a relatively short debugging period.
