AHA programming - Kent Dodds

I watched Kent Dodds presentation in React Summit 2020 and also read his aha blog post.

AHA stands for Avoid Hasty Abstractions and Kent likes it described as: prefer duplication over the wrong abstraction.

Ok, on the surface that sounds controversial, prefer duplication?
Goes against principle of DRY.
But we already follow guidelines that cause duplication e.g. WET Write Everything Twice ...but not a third time (we follow that at Opentable).
Often times you think you know a component will be reused but in fact you may be wrong and it may take a couple of implementations to really understand if it's common pattern or not. 

And that's Kents point: don't rush into abstractions.
Code duplication is ok while it's being figured out. Over time/uses the commonalities will become clear and then you can create an abstraction that will work better. He's not saying don't do abstractions, he is saying take your time to learn the domain.

In the video presentation Kent highlights concerns with premature abstractions:

  1. Abstractions can evolves past the original use case and supports use cases that don't relate much to each other any more
  2. Because abstraction exists then we end up using them even when it may no longer be appropriate.
  3. Tests get created that exist for tests only. Increases maintenance cost and people are not confident removing
This is legit. We've all looked at a codebase and struggled to understand one or more components or functions with lots of parameters and branching logic and scratched our heads. That is probably a code smell that the abstraction may no longer fit all use cases. It's also possible some of those original use cases may no longer exist either.

Read Sandi Metz, "all the little things" and "The Wrong Abstraction" which  explains how to back out of such scenarios:

  1. go though all uses and replace with inline or custom code instead of shared abstraction (re-introduce duplication basically)
  2. then you can really see similarities and what is and isn't common
  3. now you understand if an abstraction is still relevant and if so what it should be

Reminds me of a refactoring like you'd see in Martin Fowlers refactoring catalog

Kent finished the video with some parting nuggets

  • Duplication is far cheaper than the wrong abstraction, so prefer duplication over the wrong abstraction
  • Wait for commonalities in duplicate code to scream at you for abstraction
  • DRY is not necessarily a bad thing
  • if you have shared code with lots of branches then resist the urge to add more conditionals to it. Refactor it first. Learn about the callers of the abstraction so you understand what's needed


When starting on a new codebase, Kent advises take an iterative approach, don't obsess about duplication. Don't try architect app for something it's not today.

"There are no hard and fast rules. It's nuanced."

Comments

Post a Comment

Popular posts from this blog

deep dive into Material UI TextField built by mui

Image
The Material Design system is a design system used to create consistent digital experiences across platforms such as android, web and ios. Includes: a color system a typography system a shape system a grid system it addresses motion and lots more Also includes Material Theming which makes it easy to customize Material Design to match your brand. Material Design is not just a set of guidelines it is a whole ecosystem. Material itself stopped maintaining it's react implementation and recommends opensource versions.  A very popular open source implementation is  MUI ,  a react component library  built to implement Material Design . Bills itself as the "worlds most popular React UI framework" and at this time has 1.2M weekly downloads on npm and used by over 750k projects on github (did I mention it's very popular?).  Note: there are other react component libraries implementing bootstrap and ant design for example, so up to you and your design team on what you choose. 
Read more

angular js protractor e2e cheatsheet

Many from the protractor test suite category detailed task syntax example load page load a page browser.get('yoururl') browser btn actions browser back/forward browser.navigate().back() OR browser.navigate().forward() access elements on page See Protractor API list and examples from Protractors test suite access by angular ngmodel name (must match ngmodel in the html) this is the preferred approach element(by.model('person.name')); access by the css id on the page e.g, #user_name (but this can be brittle) element(by.id('user_name')) access angular binding to get generated value i.e. for {{}} element(by.binding('person.concatName')); access angular repeat list data (must match repeat stmt in the html) See Protractor test suit l
Read more

react-router v6.4+ loaders, actions, forms and more

react-router  react-router is used for in app single page app navigation, we configure routes for pages in the app to map to components react-router has over 1bn downloads, its an industry standard (but there are others e.g. Nextjs router) many apps use react-router, many on v5.x the new react-router 6.4.x the newest major version of react router v6.4 is a significant enhancement which adds a lot of new features. react-router v6.4 offers new features to load data (loaders) and handle actions (actions).  It's done gone all Remix-y which makes sense because the same guys wrote both. eliminates a lot of boilerplate code to fetch data in useEffect() and set various loading states put your data load and update logic in react-route components instead of custom code unlike Remix, react-router v6.4 is still just all on the client (not server like Remix) paradigm shifts Lets start with a couple of high level ideas; "back to the future" so to speak OR "what's old is new ag
Read more