One of the most interesting things I have learned reading "Software Engineering at Google" is the idea of code reviews. When I first was thinking about programming I thought the actual coding would take up most of the time, but it appears that code reviews can consume an equal if not more amount of project time. I also learned that there are different types of code reviews and how there are many different aspects that the code reviewer is looking for before approving a piece of code. Reading about software engineering at Google it does sound like coding and reviewing code is very much a group effort with team members switching between the roles, similar to our current group projects.
For the Markov code review I worked with my teammate Brandon Hoppens. My strategy for the Markov assignment was to first read through the entire prompt and ensure that I had a general idea of what the program was supposed to do. I then worked through the prompt building each method before moving on to the next. I built all of the methods and then ran the test after my initial build. I was able to pass a few of the test and failed others. I then went back to the individual tests I failed and manually debugged them. This was in contrast to how Brandon tackled the prompt as he was implementing the methods as they were needed. He worked to ensure each piece that he added worked with the existing code base. I think I would change my strategy to adopt some of his methods and use an incremental approach. I relied on building the entire program before running the first test, and I can see how on bigger projects this could lead to some frustration. The feedback I received from Brandon was ...
Comments
Post a Comment