152x Filetype PDF File size 0.05 MB Source: fileadmin.cs.lth.se
Andrew Hunt & Dave Thomas: The Pragmatic Programmer A comparison with eXtreme Programming Magnus Tingne D02, Lund Institute of Technology, Sweden d02mti@student.lth.se 20 feb -07 Abstract This paper is a short comparison between The Pragmatic Programmer by Andrew Hunt & Dave Thomas and the development method eXtreme Programming, eXtreme Programming is the method used in the course where this paper were written. 1 1 Introduction This comparison was performed as a deep-study in the course “Coachning av programvaruteam (EDA270)”, a voluntary course in the “Computer Science and Engineering” program on Lund’s Institute of Technology, Sweden. It was performed by reading the book while at the same time 1, XP, would advice you to thinking about how Extreme Programming do the same thing, for example what the view is on Refactoring in Hunt & Thomas’ book and what the view is in XP. To make sure that the XP-methodology was relatively fresh in mind some articles from the course were also read, see the Reference List for details. The Pragmatic Programmer is centered on short theory parts which are almost always ended with a Tip, for instance “Tip 1, “Care About Your Craft””[1]. This comparison will try to use these tips and compare them to what XP suggests. All tips can be found in Appendix A. It is important to remember that the book isn’t a complete development-method like XP but rather a guide to becoming a better programmer and writing better software. We will start by going through the main similarities in section 2 by going through some of XP’s practices and what Hunt & Thomas’s view is on those. Then I will add some personal notes on the book annd the tips in section 3. 2 Similarities with XP 2.1 Refactoring “Tip 4, “Don’t Live with Broken Windows””[1] According to Hunt & Thomas the main reason why in inner cities some buildings are beautiful and clean while others are falling apart is a broken window. If a broken window is left alone for a significant period of time the tenants in the building stop caring about their house and the house start falling apart. This can be applied to code too, if you leave what in XP is called “a bad smell” in the code for a long period of time other programmers will stop caring if their code isn’t that good either and the code will rapidly decline. 1 “Extreme Programming (XP) is a software engineering methodology, the most prominent of several agile software development methodologies. Like other agile methodologies, Extreme Programming differs from traditional methodologies primarily in placing a higher value on adaptability than on predictability.” [6a] 2 Hunt & Thomas suggests that bad code should be fixed immediately if possible, if there isn’t time it should be put on a board, commented out or just switched for dummy data until it can be resolved. “Tip 47, “Refactor Early, Refactor Often””[1] As soon as you find some code that doesn’t feel right, refactor it. If you refactor immediately you will get around to it but if you wait maybe there won’t be time for it before the customer wants it to be shipped. Then the maintenance will be much harder because the code isn’t as good as it should be. Hunt & Thomas has some suggestions on how to do refactoring, the main points are: • Never refactor and add functionality at the same time. • Have tests that you can run after to be sure you haven’t destroyed anything. • If the refactoring is big, do it in small steps. All agile methods embrace refactoring because they know that changes will occur. Bendix & Ekman [3] has refactoring as one of their main activities in Software Configuration Management. They also write that it has to be reversible so one can go back if the refactoring fails. This is also mentioned by Hunt & Thomas as a good thing and they suggests always using Source Code Control. We will get back to this in section 2.3 Reversibility. 2 2.2 Bad smells in code “Tip 11, “DRY—Don't Repeat Yourself””[1] According to Beck & Fowler [6], one of the worst smells you can have in your code is code duplication. You should never have the same code in two places. The main reason for this is since we have fast changing requirements we never know when we need to change the code. If we have the same code in several places all these has to be changed, then it’s not a matter of if but more a matter of when someone will miss to change the code in one of the places. This could lead to a lot of problems. But neither Beck nor Hunt & Thomas stop there. They say that there should be no duplication at all, in the code or anywhere else. If for example you have documentation for the code; that should be generated from the code instead of written separately (see Code and Tests in [3]). This way when the code changes you won’t have to change the documentation too. 2 “In the community of computer programming, code smell is any symptom that indicates something may be wrong. It generally indicates that the code should be refactored or the overall design should be reexamined. The term appears to have been coined by Kent Beck on WardsWiki. Usage of the term increased after it was featured in Refactoring. Improving the Design of Existing Code.” [6b] 3 Bad smells in code is closely connected to refactoring since as soon as you find something that doesn’t seem right, you should refactor it. Comments in the code is often a bad smell according to Beck & Fowler, if you see a place where the code has a lot of comments it’s most often because the code isn’t very well implemented. Hunt & Thomas agrees with this view and says that you should only use comments in the code to say why and not how. To have a comment that explains how a thing is implemented is a violation of the DRY- principle. If you change how you implement it you also have to change the comment. “Tip 13, “Eliminate Effects Between Unrelated Things””[1] Another bad smell according to Hunt & Thomas is when unrelated things affect each other. They use an example of flying a helicopter where moving one lever affects a totally different part. Since we want our code as simple as possible we don’t want these dependencies. If we change the code in one place only that part should be affected. 2.3 Reversibility “Tip 14, “There Are No Final Decisions””[1] As mentioned earlier it is very important to be able to reverse what you have done. Most programs have an “Undo” command, but maybe you don’t find the error that was caused by the change immediately but instead in a couple of days, what then? Another possibility is that you, in the beginning of the project, decided to use a specific kind of database. But then you get an order from the customer that you need to use another kind of database. If you don’t have any reversibility you are in a pickle. “Tip 23, “Always Use Source Code Control””[1] 3, not Hunt & Thomas tells us to always use Source Code Control only when programming. You should even put telephone-lists and build/release-procedures etc under source code control. This way you always have a copy of the older versions and can go back if something goes wrong. Bendix & Ekman agrees with Hunt & Thomas that having the possibility to recreate an old version of a document is important. In their article Software Configuration Management in Agile Development [3] there is a part about Version Control which allows you to recreate an old version of a document. 3 “Revision control (also known as version control, source control or (source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models and other critical information that may be worked on by a team of people. Changes to these documents are identified by incrementing an associated number or letter code, termed the "revision number", "revision level", or simply "revision" and associated historically with the person making the change. A simple form of revision control, for example, has the initial issue of a drawing assigned the revision number "1". When the first change is made, the revision number is incremented to "2" and so on.” [6c] 4
no reviews yet
Please Login to review.