Skip to main content

What’s a simple way to share and learn refactor?

 

I have been organizing coderetreat and creating screencasts on refactoring and TDD, etc… however, I find it takes lots of time and effort to organize, preparing and facilitate. (it’s not that I complain about it as a matter of fact I love it every single second and I’m amazed at how much I have learned from the community)

I have been asking myself, what’s the simpler way for me to learn to refactor and share with others? (why refactor, you may ask? it’s because it’s my favourite topic in the long never-ending list of agile technical practices) and for some reason, I really like to share my boring meme jokes, so I guess why not share a list of animated gifs of refactoring and the motivation of it.

I guess since I’m an Asian guy (hopefully some kind of descendants from Bruce Lee) so this saying is pretty cool to me:
“I fear not the man who has practiced 10,000 different kicks once, but I fear the man who has practiced one kick 10,000 times.”

Another way to look at it, from J.B Rainsberger, "I can see one large issue: programmers do not allow the various refactoring patterns to become so easy/comfortable that their fingers can execute them without conscious thought. This interferes with their progress because they have to switch more often among the questions "which refactorings will improve this design?" and "how do I perform this micro-step?" if they don't become able to perform the micro-steps (a sequence of 3-7 nano steps) easily, they might not breakthrough from "I know how to safely lead the design where I want it to go" to the more powerful "I can just start removing duplication and improving names and a good design will emerge

Don't get me wrong: the first of these 2 outcomes are good, but the second of these two outcomes is much better.

One of the consequences, of never breaking through is that the programmer will miss out on finding helpful designs that are simpler than the ones that their intuition can see.". Damn, I can smell/see big FOMO emotions running through me now!!!

and as a matter of fact, there are so many moves in refactoring, so I’m curious if I could just distill most of the refactoring moves in under 10 moves (like there’s are 10 basic numbers).

so the game plan for this article is to post as many refactoring moves/snippets as possible but then distill them and reduce them to under 10 moves/snippets.

Please feel free to copy this and make your own top 10 moves, I would be definitely interested in seeing a different list of top 10 refactoring moves so I can improve my list better.

Here goes the list

Extract Method

Motivation

  • separate the intention and implementation
  • put a name to the block of code (“Naming as a Process” from Arlo)
extract method snippet with naming

Rename method, classes, fields

Motivation

  • Easy to read code start with good naming and naming is hard
  • “Naming as a process” provides a good heuristic for naming but it’s too freaking long.
  • I find this short, simple and easier to remember from J.B. Rainsberger

Golden Master

Motivation

  • Provide safety nets for doing refactoring by leveraging Standard IO
  • It’s a quick way to provide test coverage without knowing much about the underlying code
  • It would probably be more tedious to mock out external/IO/Database call in the code.

Extract as a separate map

Motivation

  • reduce responsibility in lambda, which forces creating interface/lambda with a single responsibility


Introduce parameters

Motivation

  • enable a deeper understanding of the domain model in the code through new abstractions and it can greatly simplify my understanding of the domains
  • enable more refactorings with capture the common behaviours over these new abstractions

Introduce indirection steps to avoid big steps

Motivation

  • to avoid breaking all existing clients when introducing new fields, new classes, etc...

Steps for approach 1

  • create a warm, dry place where the code can be changed and disrupt client less
  • focus on changes inside the warm, dry place
  • publish the changes when they're ready, which often means inlining the warm, dry place (put it back where it was) or inlining the clients of the warm, dry place (the new code replaces some older code)

Steps for approach 2 (introduce parameter object)

  • https://www.youtube.com/watch?v=hGkdDxYCCKY&ab_channel=tomphp
  • intellij refactorings: extract methods, make method static, introduce parameter object, convert static to instance methods, introduce the field

Steps for approach 3 (adding the wrapper)

  • extract a function that takes the primitive value f(p)
  • introduce parameter object to wrap p into wrapper w, so that now we have f(w)
  • move f() onto class W. (What's left is moving any behaviour that asks for w.getP() onto W)
  • for all remaining function g(p) put in the line w = new W(p) and then migrate all the internals from p to w.p (or w.getP() or whatever you call it)
  • extract parameter on new W(p), so that g now takes a w instead of p
  • move g() onto W
  • intellij refactorings: extract methods, wrap-unwrap (introduce indirection), introduce parameter, move method to another instance, introduce the field

Steps for approach 4 (liberating the wrapped)

  • extract all the functions of p that you want.
  • promote p to a field on the current class
  • extract delegate to class W, creating a new class that as p as a field, leaving behind this.w = new W(p)
  • clean up
  • intellij refactorings: extract methods, extract delegate

  • introduce parameter object

  • make method static

  • extract method

  • extract delegate

  • wrap-unwrap value (introduce another layer of indirection)

  • introduce parameters

  • move method to another instance

  • introduce field



…still under construction and more to come on the list

References

Labels:

Comments

Post a Comment

Popular posts from this blog

growing object oriented software, guided by tests summary

Key ideas practice TDD as a design technique and not as a testing technique Software development as a learning process. Expose uncertainly early by testing our assumption as early as possible we use mock objects to identify the essential interactions between modules/objects. This leads to more effective abstractions, which reduces the cost of changing the cost safely over time. Stub queries; expect actions??? Write code that depends as little as possible on its context. programming by intention Test-Driven Development (TDD) and Quality Software development as a learning process. The best approach a team can take is to use empirical feedback to learn about the system and its use and then apply it back to the system. Development is incremental and iterative. Incremental development builds a system feature by feature. Each feature is implemented as an end-to-end slice. As a result, the system is continuously integrated and ready for deployment. A system is deployable when the acceptance t...
Post a Comment
Read more

How to Win Friends and Influence People summary

Principles Fundamental techniques in dealing with people Don't criticize, condemn or complain. This makes them defensive and justifies their actions. Instead, praising them lowers their defense and they will be more receptive to your feedback. give honest and sincere appreciation arouse in the other person an eager want. become genuinely interested in other people i.e.: remember other people's birthdays send linkedin messages of congratulations when someone in your network gets a promotion or professional success coordinate office parties for personal celebrations such as births, accomplishments or birthdays. people crave the feeling of importance. "What is there about him that I can honestly admire?" appeal to the other person's interests. Virtually all people care more about what they want than what you want keep asking yourself - "what is it that this person wants?" everyone has something they can teach you, and you benefit by figuring out what that i...
Post a Comment
Read more

Code Retreat 2017 retrospective

  In general, this year is much better compared to previous years There are several important points that I need to write down Typically, the main reason for me to do code retreat to help developers in the community to expose more to TDD/craftsmanship. Recently, I asked myself question: “How come it’s not eas y  to adapt TDD, automated testing which should be the core value of any efficient teams?” I don’t think that people is lazy or people is resistance, I think as the industry, there’s lots of ambiguity in how people should approach TDD (SOLID principles, 4 simple rules of design, etc … are too generic) and agile practices (agile manifesto, etc…) How can I apply SOLID, 4 simple rules of design into my day to day jobs? What’s the most important reasons for developers to write automated tests? is it testability design, is it executable documentations?…. what’s the different between integration/component/API tests? should we care? when I discuss about unit tests with QA, typic...
Post a Comment
Read more