Reusability: Is reusability too much work.
Often at work people come to me and ask me questions like
“I have to make this component which does (something) and It may be used at other places but should I make it reusable now with the extra effort or see if it's being used and do it then.” To which I generally reply with more questions like:
“How much time do you have.” or “How many chances do you think this has of getting reused.” But even though I try to get the decision-making points across I think they get lost in the scope of that argument. So here is my attempt as providing a spec for how I make this decision for my code.
“Think Big Picture and Reuse small”
You need to scope the component out before you begin and see the component in different scenarios before you begin. Way too often people get a mockup from the UX team and they just start building it, which works but doesn't work well. You need to visualize the final result before you build it you need to see it being used. If you don't see the bigger picture you can never get the small details correct and reusability is always for the small gears and cogs not for the car.
When you imagine a truck being built you don't imagine them welding cars together. You imagine them bring together tires, steering, chassis, and an engine. Car manufactures often reuse car engines because they are a small part of a car that does just one thing, give us power in exchange for the long-term death of the earth.
Similar techniques should be used for usable components. Reuse small and reuse more, reuse big and reuse less and with more maintenance the decision is yours. One very simple example I see of people doing this very wrong is making list components that create a certain type of list instead of simply creating the list item component and then repeating the same using any strategy provided by the library/framework.
“WET and DRY”
Another thing I see people disregard is the weighing of effective tradeoffs(wet). People think that code decisions are absolute if it works in one case it will work in all of them, which isn't really true. Code is as much a science as it is art. A balanced piece of code is almost always beautiful. Balance is achieved only when you know the tradeoffs to when something is worth making reusable as compared to when something is good enough to be a one off. Often in our work environment, client needs are evolving and this means certain things we never thought would become reusable do and with time constraints we have to decide if making it reusable is worth the tradeoff. In comes the DRY technique which simply says “dont repeat yourself” and now you might be thinking ok then I should just make the original component reusable even when I don't have the time to do so. Not quite! You should develop a sound pattern for your dry usage. I for example in those cases will use the good old copy and paste (And commit this sin only when I don't have time) for two copies of the code but as soon as I have to write a third copy would prefer reusing the first block and refactoring the second block to do the same. This makes sure that you are reusing something truly worth reusing and provides much clearer reusability use cases to make the component dynamic rather than constrained to just 2 use cases.
All the blathering done, and stuff said. These however are just my thoughts and should be taken as such, the words of a mere mortal. Learn to learn from your code and make your own decisions and mistakes. I promise you coding has never been more fun than when I made stupid silly mistakes that taught me what I should have done in the first place. Listen to people but don't think anyone knows everything about anything.
Peace out coding monkeys!
