A `Slice and Dice' Refactoring
When methods focus on a single responsibility, they fall into two broad categories. They are either queries that compute and return some value without producing side effects, or they are commands that change the state of the world or the state of the object they are on.
The former style is more common in functional programming. In . . .
Using Edge Cases as Focal Points for Design Choices
One of my favorite sayings is “If you take care of the corners, the room takes care of itself.”
For the longest while I thought it was something that Frank Lloyd Wright had said but I haven’t been able to find an attribution. Regardless, I think that the idea is sound. The edge cases in our software define it. Ideally, we shouldn’t . . .
Making Usage Patterns Explicit in Code
In nearly every OO application there’s at least one large class. By large, I mean a class that has 15 or more methods. We expect classes to have focus and it’s hard to make the case that a class with that many methods is about one thing. There will be some sort of grouping. Sometimes it’s explicit in the names of the methods, sometimes it’s . . .
Using Static Call Counts to Explore Internal Structure
In an ideal world we’d be able to see more in our editors and IDEs. We see our code, and that’s just about enough to work but there’s so much more that we can know.
One of the things I’d like to know is the number of call sites that each method has. In frameworks or libraries, we’ll have methods that are never called . . .
How Social Media Architecture Affects Group Cohesion and Behavior
Before I started programming I majored in architecture. I have a strong visual imagination and as a teen buildings just “popped” into my head without me putting them there. As a career, it seemed like a natural fit but unfortunately I never really learned how to draw well enough so I moved on to engineering and computer science. . . .
I’ve been hearing people talk a lot more about Technical Debt recently. I’m glad. Anything we can do to pay more attention to long term quality is good. Technical Debt is a valuable frame for those discussions. No one wants to be in an impossible situation and teams that keep accumulating Technical Debt often end up there. It’s a land of . . .
A while back I wrote about what it takes to kill code. I won’t take up any time repeating why it’s a good idea to get rid of code that’s dead or low value. I think that anyone who’s spent time trying to understand or change some area of code only to find out that it’s never really used knows how frustrating it can be.
As often as . . .