Dr. Brooks
Addison Wesley Longman Inc.
Chapters 13-15:
In these chapters we find out about some of the more technical aspects of design and why they are important to us as computer scientists. The first part is about the whole and its parts and how any man can write any program it is based on if you do it correctly. The chapter then almost goes into a brief overview of everything we read about in Xtreme Programming Installed such as bug proofing programs, testing all the parts, top down design and the like. It did not go into the specifics on how to do this but rather overviews of each of the parts and why they are important. The latter half of the chapter was almost completely about debugging from figuring out what component and system bugs are and how to handle them both, to figuring out test cases for the two and determining patterns on how to solve them to important aspects of design such as paying attention to one component at a time. There was a bit at the end about quantizing data that was confusing. The next chapter was about hatching catastrophe and the steps that need to be taken in order to prevent a large error in your programming. The interesting part of this is that the first solution presented is to make milestones and not millstones, that is, if something is taking too long it is likely that it is not being done correctly or is being designed in such a way that there is going to be a lot of bugs in the software. In general, software should be relatively simple and anyone should be able to recreate what you did if given the time and the people. Software that isn't properly designed will just make the lives of those who need to use it later harder and likely they will spend more time figuring out what was done rather than how to fix it. They also talk about how you cant brush problems under the rug and this usually results from the conflict of roles in the office place. They say that management needs to be willing to yank the rug out and find out what is going wrong with something if an issue surfaces. The last chapter talks mainly about documentation and why it is required and important for every program that you write. There is a list of 10 things that are given to tell why it is important and why it is needed for each program. The author also actually says that flow charts are a bit of a curse and can at times be misleading. He rather says that you should have code that is very self-documentable and this should make the process much easier on you and the people who will use your software later. In all the chapters covered some of the rather difficult parts of design and let the reader know some simple things on how to prevent them.
The chapters were actually rather interesting and what I find more interesting is despite the amount of information that was said it was a relatively quick read. I think my favorite part was about hatching a catastrophe as just the initial setup of a program or the way something is defined can set it up for failure. If one tries to make one large code segment that does a very complex operation that can only be seen by the person who wrote it then likely that design needs to be broken into smaller parts and those parts need to be tested. I am a large advocate of writing small tests and making sure that all work mostly because that is what I am going to be doing at my job at Halliburton later this year but also because I have written many programs in academia and I have never had sufficient time to write small iterations and tests that I know would have been beneficial to the programs success. This leads into the next part of the text which talked about documentation and I believe if I had time to write these small tests that I would likely be able to site my documentation really easily instead of, basically, having one person from the group do the dirty work and write the documentation on his/her own. I think that the part on the whole and its parts were good and it did talk about debugging which goes hand in hand with testing but I feel like this was more of a recap of the Agile stuff that we have all learned. It seemed like the same lecture over again, program in pairs, test to find bugs, make user stories, make them small and estimate their time etc. I feel like this might only be so because I have had A LOT of readings this semester and a few of them have been similar. Despite this this was really one of my favorite set of chapters and I can only hope that the next chapters will be as informative as these were.
No comments:
Post a Comment