Refactoring

Large-Scale Transformation and the Bias for Action

Continuing on our conversation about large-scale transformations, I want to talk about change-harvesting’s “bias for action” and tell you a weird thing I did in kontentment the last couple of days. Change-harvesting takes the stance that our most reliable strategy for change is a highly iterative process of act-look-think, in roughly equal proportions, repeated in small local cycles. We oppose that approach to look-think-act, emphasis on think, in large global cycles. This opposition is, of course, not a philosophical light-switch, […]

Large-Scale Transformation and the Bias for Action See Full Post

Large-Scale Refactorings

Large-Scale Refactorings — given the recent refactoring-related muses, a respondent asked me to talk about large or larger scale refactoring work. (I love it when people’s questions trigger my writing. Please do ask these things.) First things first, “large scale refactoring” is really a colloquial expression, a shorthand we sometimes use, but in my experience there is no such thing, for two reasons. The first reason is definitional. Remember, refactoring doesn’t mean “changing my design”, it means “changing my design

Large-Scale Refactorings See Full Post

Second-Order Refactoring: Narrow The Question

Another small second-order refactoring for you today. I call it “narrow the question”. If you’re asking an object for data, ask for exactly what you want to know, instead of what you’d need to compute what you want to know. A very simple example: the PlayerView wants to disable/enable some of its controls when the Player is actively playing. In the "before" code, PlayerView asks the Player for its PlayerState and decides, based on its value, whether that means the

Second-Order Refactoring: Narrow The Question See Full Post

Second-Order Refactoring: Swap Supplier and Supply

As a hardcore user of TDD and refactoring, there are a number of what I think of as “second tier” refactorings that I use quite frequently. In one’s first intro to refactoring, one sees a lot of "rename", "re-order", "inline", and "extract". These are pretty potent tools, don’t get me wrong, but I think of them as, idunno, atoms. I think of these "second order" refactorings as small inorganic molecules. An example of this would be one I call "swap

Second-Order Refactoring: Swap Supplier and Supply See Full Post

How I Work – Preaching And Practicing

This entry is part [part not set] of 1 in the series How I Work

A respondent asks, "Are you always able to practice what you preach? I don’t mean intentionally dropping but unintentionally as your mind is sloppy. I have great difficulties in applying 100% of my "knowledge" 100% of the time." Sometimes questions open up huge areas with lots of issues and subtexts and angles, and this is one. It’s too big to fit in one or two tweets. First, the direct answer: Oh, hell no. I am definitely not always able to

How I Work – Preaching And Practicing See Full Post

Refactoring Pro-Tip: Scanning Isn’t Just Fast Reading

Refactoring Pro-Tip: When I’m scanning, I’m not just reading fast, I’m feature-detecting, something the unconscious part of me is very good at doing, especially when the code helps. Part of the made, the making, and the maker as a guiding theme for me is the idea of "leaning in" to the strengths of my maker body and "leaning out" from its weaknesses. A trivial case: one reason TDD works so well for me is that the microtests give me a

Refactoring Pro-Tip: Scanning Isn’t Just Fast Reading See Full Post

Refactoring Pro-Tip: I Optimize Scannability, Then Readability, Then Writability

Refactoring Pro-Tip: I optimize my code for scannability, readability, and writeability in that order. I won’t argue my case in detail, there’s a video if you’d rather watch me make it instead of reading it, and I’ll just sketch the case briefly here in the muse. http://geepawhill.org/optimizing-a-program-and-programming/ When I’m coding, I notice that I spend significantly more time scanning the code than I do reading it, and significantly more time reading the code than I do writing it. So when

Refactoring Pro-Tip: I Optimize Scannability, Then Readability, Then Writability See Full Post

Refactoring Pro-Tip: Making Local Variables Maximally Local

Refactoring Pro-Tip: When I tackle a long method, the first thing I do is make my local variables maximally local. Consider this psuedo-code. It’s basic stuff, I’m betting virtually any geek can read it, but if not, lemme know. longMethod( int y ) { int x; x = 0; // … // IRRELEVANCY #0: 87 lines that neither read nor write x // … if( y == 17 ) { x = 1; } // … // IRRELEVANCY #1: 87

Refactoring Pro-Tip: Making Local Variables Maximally Local See Full Post

Refactoring Pro-Tip: Naming, Isolation, and Noise-Filtering

Refactoring Pro-Tip: I use naming, isolation, and noise-filtering as strategies to keep the coder’s intention at my fingertips. (I’m actually jonesing to write some geeky material in this series, but I’ve got one more of these pesky abstract philosophy things before I can get there.) First, a silly line from a silly movie, Airplane, which makes for a good Friday night comedy if you want that. (Paraphrased from memory.) "There’s a problem in the cockpit." "The cockpit? What is it?"

Refactoring Pro-Tip: Naming, Isolation, and Noise-Filtering See Full Post

Refactoring Pro-Tip: Refactor to Enable Change

Refactoring Pro-Tip: The triggering events for refactoring vary, but the reason we refactor at all is the same each time, regardless of occasion: we refactor to enable change. The most obvious and direct occasion for a refactoring is this: I want to add new functionality and preserve old functionality, and it will be easier to add if I first schmoosh the old functionality around a little to make a little hole where the new stuff will fit. When I do

Refactoring Pro-Tip: Refactor to Enable Change See Full Post

Scroll to Top