Iteration 1 reflection

| No Comments

For me and my project partner, iteration one goes smoothly in general, in spite of some small trouble in the mid of the way. Now it's a good time to reflect on what we have learned from this process. The reflection will stay on a high level, without going into much detail about the coding and implementation itself.

We started by planning for the whole iteration. This turned out to be very critical, as inappropriate implementation planning and unclear work division between two persons brought trouble to us later on. Unfortunately, we didn't spent enough time on this critical part. We are too eager to start programming, and a little time was spent on discussing what to do in total. So what happened later on was that, for a few times, some overlapping appeared between our individual work, and sometimes hard to merge them. Then we needed to reconsider and someone had to try to combine the two jobs. This definitely cost much time unnecessary. So in the future, for the next iteration, we certainly should spent more time on planning and job division before getting our hands onto any specific tasks.

The next part, as mentioned in the class, should be writing all test cases, including unit tests for helper functions and overall tests for the whole class method. My partner was mostly responsible for this task, while I also wrote a few. While writing these tests, we realized that if you had a clear mind of what functionality of a unit should have, then writing the tests cases becomes obvious; otherwise you would suffer a lot from not knowing what to test. However, it's still possible that later on you would find out some thing new to be tested, or some other tests cases for some previous tested units. This is due to our growing understanding of some specific functionalities, or change of requirements. Fortunately it's typically not difficult to modify tests cases, and we indeed had not trouble with this part.

After some simple skeleton for our classes and methods, we began real coding. Here our group had both good lucks and bad lucks. The good thing is, since we already got codes from previous lab assignments for most of the functions that helps a lot this iteration, the program structure and implementation seemed straightforward to us, hence minor problem occurred during thinking what to code and how to code. However, the unexpected issue came from the collaboration. In particular, for the scan method, my partner finished half of the method and I was supposed to do the other half. But the moment I saw his piece of code, I realized that his way of implementation was totally far from what I was thinking. So then I could not carry on with what's in my mind, nor could I continue to finish the other half. We had no choice but to stop and discuss which version should we stick to. This was totally not easy! I insisted on my way, while he preferred his. We argued again and again about which one is better, and it only turned out that either one is correct, just a matter of taste. In the end, I complied to his version so that he didn't need to rewrite what he had for then, but I felt uncomfortable. And what we learned from this is that it's important to discuss between us the implementation details before we move on on one's own, especially when we are both trying to do coding in the same small unit.

Regarding the usage of svn, it indeed provided us with a good platform of storing and exchanging individual works, as well as merging them as a whole. We also used the version control functionality once, meaning that reversing to some previous version when we messed up the current one. I was also really worried about the svn conflict issues before we began the project, but it turned out smoothly as we would sit together and discuss about the conflict every time such things happened. In a word, svn really served as a useful and convenient tool for group collaboration, and we should definitely continue to use it for upcoming iterations, as well as other future work.

In the developing process, I paid special attention to possible future requirement changes, e.g., new outputs required from the scan method, change of keyword tokens, etc. So what I always kept in mind is that trying my best to make the code modifiable.

One last thing about this iteration is that I paid attention to program logical structure and proper comments, so that the codes became more readable. We will stick to that also in the future iterations.

Recent Entries

Find recent content on the main index or look in the archives to find all content.