Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley
Chapters 10-12:
In these chapters we look at three very important, and now, practical, parts of the EPI guidelines which are: Quick Design Sessions, Programing and Pair Programming. Quick design sessions were the first to be discussed and were rather glossed over. They said that if anything these should be short 10 minute meetings on what needs to be done as well as a learning and catchup process for all the programmers to be able to understand where the project is headed and what their individual code is going to be incorporated into. They said that most of the learning in these will take place in the first three to four minutes then the planning is done in the remainder. The second issue they talked about is actually writing code; programming. They talk about the idea of starting by getting a simple piece of code into the machine and then testing it. The basic idea is that you want to write things that are as simple as possible and you want to make sure you use code that you have used for years. Everyone remembers how to write things such as adding up a list of numbers so try to make each item you work on feel that way and be designed similar to this very basic program. It would then make it very easy for you to go back later and change it if you found a faster way to do it that possibly used less cycles. Essentially they think that you need to keep four rules in your mind while programming: 1. Run all the tests 2. Express all ideas you need to express 3. No duplicate code 4. Minimum number of cases and methods. They then talk about a number of other techniques that are all very good to practice. Refactoring- the process of improving codes structure while keeping its performance, whether this is changing the way the code calls an object or adjusting the spacing and notes. Continuous integration- where programmers should be constantly putting everyone's code together and making sure it compiles in a reasonable amount of time. Coding Standards- make sure the code communicates and clearly as possible and maintains the standard that you want to uphold. These can be things as simple as indentation and as complex as naming, capitalization and commenting. Essentially, you want all the code to look as if it was written by one person when really it is a group of people who all have the same set of standards. To continue with this, they then talk about pair programming which is when people work in sets of two or three and make sure that both people are engaged in the code writing to help reduce mistakes and make sure that the idea makes sense to multiple people before testing occurs. Essentially the two work as a pair, one drives (does all the typing) and the other is checking the code as well as discussing ideas and making sure that the driving isn't making mistakes. When the driver does mess up the two switch or if the driver is less confident they stop, fix the issue and make sure to slow down to avoid the mistake again. It is a process that takes awhile for some, but eventually it becomes common place for workers to make their own pairs and take interest in others coding practices.
Pair programming is actually one of the things I wish companies would practice more. It seems like companies devalue this because it assumes that two people working on the same piece of code would somehow slow production when really a lot of times people end up asking others for help and the two of them end of getting both peoples work done in the same manner. I also really like the ideas of the coding practice that were discussed because they establish the idea of good object oriented programming which makes it much easier for someone to come along later and update your system without having to completely understand how it works or what every line of code does. It also does help to reduce the number of duplicated lines as you might be calling the same method a few times and it helps to write it once and then be able to just use it the rest of the time you write the program. This also does enable the user to break the program into smaller tasks and write simpler pieces of code rather than having to make long complicated methods in the main. Many of the commonly used languages today are very good about being able to integrate methods easily into a program and make accessing them quite easy. C++ even goes so far as to allow the user to access individual pointers that allow the user to touch the memory where the action will be set directly. I think the idea of quick design sessions are good but there was less than a page on them and they didn't entirely explain what you are supposed to get out of them other than more clearly defining parts of the program one of the programmers doesn't understand. The other thing that I dislike about all three of these chapters is while these might be doable in the business world, these are very hard to do in undergraduate academia, when each member of your group has 15 hours of class to take and 6-10 blogs to write per week, sometimes this system could just be more work than it actually would help your group.
No comments:
Post a Comment