I was browsing around the Extreme Programming Wiki today and came across the entry on short methods. I've always tried to keep methods as concise as possible myself and IMHO, the advice on the page is quite good. It even attempts to provide some balance by suggesting that sometimes longer methods are okay (and even cites some examples).
For me it comes down to clarity. I don't like to have to think too hard. If a code is factored into multiple methods with well-selected names, then it can be (generally) easier to read and understand. My first mentor, Wilf Lalonde used to have what he called a 'five second rule': if you can't understand what a method does in five seconds or less, then it's too complex and needs to be refactored.
I recall a study (and really wish that I had the reference) where something like 10% of an average software developer's time is spent writing code. The other 90% is spent reading code (some portion of it must also be spent reading Dilbert and checking on stock prices). Developers read code because they need to know how to hook into it, extend it, modify it, etc. The net of this is that making it easier for a developer to read code will have a larger impact on developer productivity than making it easier to write code. This is a little glib, as reality is a lot more complex, but I believe the theory is sound.
Anyway... as a general rule, I never make long methods; I always factor my methods into relatively small pieces. As always, balance is key: the challenge is to not factor things too finely. My rule is to try and do "one thing" in a method. That one thing might be to open a file and then pass on processing of the file to another method (I guess that's two things...), or to parse out a particular object from a node in a DOM tree (in all cases, "one thing" generally involves the execution of more than one message).
[Updated to actually include the link to the wiki page][Read More]
Eclipse hints, tips, and random musings
Wayner 1000002UYQ 800 Visits
Wayner 1000002UYQ 1,328 Visits
To be completely honest, I not completely comfortable with the title, but it the one that Mike gave me. When I told my in-laws that I was leaving my job at IBM to become an "Eclipse Evangelist", they looked at me with that odd sort of open-mouthed look that is normally accompanied by the words "you're doing what?" My wife's family is very involved in the church; several of them actually have the title of "Evangelist" themselves. Indeed, there appears to be no dictionary definition of the term that doesn have something to do with the church.
According to Wikipedia, "the word evangelist comes from the Koine Greek word ('eu-angelos'), meaning bringer of good news." I can live with this definition. As an "Eclipse Evangelist", I see it as my job to comment on all the goodness that's happening in the Eclipse community. That's not to say that I won't ever comment on things that I think need improvement, because I think the community benefits from balance and honesty.[Read More]
Wayner 1000002UYQ 882 Visits
I recently had an opportunity to speak with some folks who are considering a migration from a loose collection of Microsoft-based technologies to Java. Their current collection of applications have been developed over a number of years and they have decided that it is time to revisit their existing architectures and start rebuilding their assets from the ground up.
Being a "Microsoft shop", they started by looking really hard at .Net. They were pretty far along that path before I got a chance to talk with them. Frankly, I'm not sure how that was working for them; however, since they'd spent quite a lot of money coming to visit with me to talk about Java, I tend to believe that it wasn't going well (I'll try to discover some of the details for a later posting).
Their existing applications provide the user with a pretty rich experience. They make use of some pretty sophisticated user interface designs that their user community is very accustomed to; migrating the rich client to a browser-based application was not an option. The applications all access backend resources (primarily using Microsoft Transaction Server (MTS)) to invoke business logic. Generally speaking, the applications are designed pretty well.
The backend is a pretty good fit for J2EE. Specifically, Enterprise JavaBeans (EJB) is a good technology to substitute for MTS. We talked a lot about the various persistence options available (in the end they favoured a "roll your own" option, which I'm not sure that I'm comfortable with) as well as the bevy of technologies available to the Java programmer.
When it come to the rich client user interfaces, Eclipse Rich Client Platform (RCP) is a natural fit. One of the big benefits they'll get from RCP is consistency. Right now, they have a collection of eight different applications that all look and different. They make the look and feel consistent by building these eight applications as Eclipse features (probably each with a collection of plug-ins). By deploying all of these applications in a single RCP application, they may potentially reduce their footprint. To boot, everything they build for RCP will work on all the platforms that RCP supports (Windows, Linux, Mac, ...).
By building each "application" as an feature, it is also possible for them to "mix 'n match" the functionality that is made available to each user. By simply excluding a feature, they can prevent certain types of users from having access.
One of the classic problems with rich client applications is that, as they are rolled out to more and more people, updates become very difficult. The provided update management facilities in Eclipse can help users to make sure that their applications are up-to-date.
My friend Roland Barcia co-authored an article describing how to make an Eclipse RCP application that uses WebSphere Application Server on the backend.[Read More]
It wasn't an easy decision, but I've left IBM and have joined up with The Eclipse Foundation. IBM is a great company to work for, and IBM Software Services for WebSphere (ISSW) is a great organization within the company to work for. But I simply couldn't pass up the opportunity presented by the Eclipse Foundation.
Perhaps the thing that I will miss most about IBM is working with some great folks. Of course, I'm trading in one group of great folks for another; but still, it's hard to walk away from a great group of people that I consider peers and friends. If you need help with WebSphere, contact ISSW: they're the best (I can say this sort of thing without bias now that I'm no longer part of the organization).
Seeing as I am no longer an IBM employee, I assumed that I'd have to give up this blog. However, I (apparently) get to keep it. How cool is that? I guess some readers might think that this is no big deal. A lot of people in the community think that IBM and Eclipse are pretty much the same thing. They're not. There is a lot of IBM influence in the Eclipse community, and for good reason: IBM is a strategic member of the Eclipse Foundation. However, there are many strategic members of the Eclipse Foundation and each of these members exerts the same kind of influence. Take a look for yourself.[Read More]