No-Brainer Refactoring with Byke
It is very difficult for computers to read handwriting, a trivial thing for us human beings. Computers beat us at chess but they are no better than mediocre amateurs at playing the game of go.
That's because computers are good at crunching code whereas human brains are honed for feeling, for recognizing and reacting to patterns. That's also why I am a much more productive and relaxed programmer using Byke.
Byke is a nifty Eclipse plug-in that shows the dependencies among the elements in my code and gives me immediate visual stimulus from what I'm doing. When you encounter a familiar pattern in your life like a friendly face, an angry animal or the smell of food, you don't have to think. You simply feel it.
The diagram above was produced in realtime from this class from an actual project of mine (a calendar app that sends email reminders).
Take a look at the code. Are all refactorings immediately obvious? Can you feel them? Do you see the dependency cycles? Which members (fields and methods) can be extracted? Can you >feel< any clusters among members that can be extracted together?
No. These things are not easy to see by looking at the code.
Byke tries to layout the diagram as best as it can, but often the result is ugly, unpleasant. Ugliness/beaty and pleasentness/unpleasantness are FEELINGS I get without having to think about code at all.
Dependency cycles are shown in red so they stand out like the sore thumb they are. I introduced a method call just to see the dependency cycle in red, above. After removing it, this is what we get:
Clicking on the "sendRemindersTo" box highlights its dependencies in blue, above.
That diagonal blue dependency pointing up and crossing several boxes is >annoying< me. My first reaction is to think: "Byke sucks! I could layout this diagram much better manually! I would just have to pull that box up.". Then I took the humble approach and thought maybe my own code wasn't all that clean... maybe there was some refactoring I could do. Hmm...
That box is being pulled down by the arrow to "isToday". I realized those four static methods selected above go together nicely so I moved them to a CalendarUtils class. The diagram is less cluttered already:
WHOA! Now I can >see< an entire tree above, on the right side, separate from the rest, apparently used to "choose" something. Can you see it? Without even having to know about what the code does we can >feel< the class is not cohesive. We can extract that tree to its own EventChooser class:
That leaves us with a result that is simple and cohesive:
No brainer.
That's because computers are good at crunching code whereas human brains are honed for feeling, for recognizing and reacting to patterns. That's also why I am a much more productive and relaxed programmer using Byke.
Byke is a nifty Eclipse plug-in that shows the dependencies among the elements in my code and gives me immediate visual stimulus from what I'm doing. When you encounter a familiar pattern in your life like a friendly face, an angry animal or the smell of food, you don't have to think. You simply feel it.
The diagram above was produced in realtime from this class from an actual project of mine (a calendar app that sends email reminders).
Take a look at the code. Are all refactorings immediately obvious? Can you feel them? Do you see the dependency cycles? Which members (fields and methods) can be extracted? Can you >feel< any clusters among members that can be extracted together?
No. These things are not easy to see by looking at the code.
Byke tries to layout the diagram as best as it can, but often the result is ugly, unpleasant. Ugliness/beaty and pleasentness/unpleasantness are FEELINGS I get without having to think about code at all.
Dependency cycles are shown in red so they stand out like the sore thumb they are. I introduced a method call just to see the dependency cycle in red, above. After removing it, this is what we get:
Clicking on the "sendRemindersTo" box highlights its dependencies in blue, above.
That diagonal blue dependency pointing up and crossing several boxes is >annoying< me. My first reaction is to think: "Byke sucks! I could layout this diagram much better manually! I would just have to pull that box up.". Then I took the humble approach and thought maybe my own code wasn't all that clean... maybe there was some refactoring I could do. Hmm...
That box is being pulled down by the arrow to "isToday". I realized those four static methods selected above go together nicely so I moved them to a CalendarUtils class. The diagram is less cluttered already:
WHOA! Now I can >see< an entire tree above, on the right side, separate from the rest, apparently used to "choose" something. Can you see it? Without even having to know about what the code does we can >feel< the class is not cohesive. We can extract that tree to its own EventChooser class:
That leaves us with a result that is simple and cohesive:
No brainer.
posted by Klaus Wuestefeld at
6:41 PM
|
1 comments
