Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Going to Extremes : Page 4

Developers should be fully aware of the risks of the extreme programming methodology.


advertisement

XP vs. OOP
XP says don't design and code for reuse until reuse is needed. Don't spend money for something until you need it and until you know just what you really need. This goes against one of the holy grails of object oriented programming (OOP), but it is a reflection of how things work in the real world. This is in line with XP's basic philosophy of simplicity: Do the simplest thing that works; and don't design or code for possible future requirements.

Another sacred cow of OOP is the ability to delegate responsibility to an isolated modular object or API, and hence, the ability to delegate work to an isolated, modular, cubby-holed programmer. In XP, however, not only are programmers required to work in pairs, they are required to eat in groups, sleep well, develop basic social skills, and, one would assume, bathe. In addition, all team members are free to mess with others' code. While individual areas of expertise may be thinner, groups no longer find themselves overly dependent on any one individual.

Then there is bad code. Bad, untested, overly complex, buggy, inefficient, unformatted code. Code written by "the other guy." In the world of XP, tests are written before functional code is written, code is written in pairs, and anyone on the development team is free to refactor and/or rewrite anybody else's code. So there is no longer an "other guy" and, as a result, no bad code. One can only hope.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date