Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley
Chapters 13-15:
In these three chapters they were all mostly about testing and iterations with chapter fifteen diverting a little and talking about releasing code. The important thing that thirteen and fourteen pushed was the idea of writing tests for EVERYTHING you possibly can and making sure that for each few lines of code you have you have a test. Even if this means that the compilation and testing begin to take awhile you need to make sure you test each piece of your code and if the task takes too long then you need to reevaluate the test and try to make it more efficient. The newest and most interesting concept in these chapters was the idea of writing a test as though someone had already written the code, or programming by intention. This is the idea of figuring out what you need your code to display at the least, making it display this information and then working backwards to figure out the code and developing a test for it at the same time. The author even goes so far as to provide and example of him and a coworker working on a method in smalltalk programming by example and then writing the test for it to make sure it runs. The two do all the practices seen before of communication, documentation, naming and even pair programming. They don't really care about names at first and simply let things like names and variables happen organically and simply write what they intend for the code to do. The two go back and forth and as things don't make sense or begin to take too long they change it and make it very easy to understand. The fifteenth chapter talks about how while working you need to be saving and then releasing your code often. IT also talks about how conflicts can occur with releases so it is important to check with your colleagues to see who has what checked out and if there are some conflicts that arise to step through them, combine them, or simply archive both and then talk about it at your next stand up meeting. It is an important skill to learn for working in an Extreme programming group and will eventually help the writers to learn each others tendencies and work through problems.
I think these articles were very interesting but they left me with a lot of questions as to simpler ways to handle some of these things. The earlier part of the book talks so much about generating clear user stories and that each person needs to sign up for them and what not but when we get to this chapter it as if some of these practices are not quite applicable. The pair programming part of their work was interesting but it did not seem like the two were stopping each other when mistakes were made or when something didn't make sense. Perhaps it was that they both thought it worked at the time and then decided later it did not but they had to backtrack quite a bit and after a little while the example became muddled. I guess personally it also didn't help that they were programming in smalltalk and I have never used it before so some of the syntax was foreign to me and I didn't take the time to look it up. I also am really confused about releasing your code often and how they say to handle conflicts. If you and another coworker both finish early and end up working on another item and find you've both checked it out (somehow) why wouldn't you simply go to the other person and say "hey I did this what did you do?" and see whose solution works better and whose is easier to test. Maybe this was discussed and is not part of EP but it seems like a much simpler solution than trying to guess and see whose is correct. I do like the idea of coding by tests as just having a test may stop you from making a mistake or making the code too complicated.
No comments:
Post a Comment