Please enable JavaScript.
Coggle requires JavaScript to display documents.
Code Sharing & Extending (INTRODUCTION (you learned to abstract and…
Code Sharing & Extending
INTRODUCTION
-
sometimes there's big expectations of your code. it starts to get momentum and the team increases, maybe spawns into several teams with different responsibilities, clients, purposes.
you instinctively tidy things up and extract concepts, preparing for it be parameterizable and instanced to solve multiple problems
-
THE COST OF ABSTRACTION
the code was straightforward but you found patterns, places of extension, plugins, parameters. you can't help but expose those.
you think, this is perfect! the next guy will pick it up where I left off and make it work for use case y. The next guy may even be you. just not today. and not without loads of additional files and modules having spawned around this all.
so to recap. the concept/feature was simple but served only the sole purpose of your task at hand. you made it more generic. and therefore with a more complex API. This API is your expectation of where and how it can diverge its use but you won't exercise it just now. This work is subjective and needs documentation to be grasped.
TIME, EVOLUTION, LEGACY
the reality is that as projects evolve, requirements evolve, your understanding of the ecosystem does too. teams evolve and the purpose of the code may be more broad now.
you now need to revisit this file/concept/module. you find the API doesn't match your needs. you find dependencies that are deeply embedded and hard to parameterize. you find asynchronous steps which don't fit your outer shell
your work is part of the project, is in use and can't be reapplied here. you feel an urge to create a new copy of it for other purposes. the idyllic view is gone.
RECAP
this is not to say you should not generalize.
It's more to make you think that:
a) when you do you inherently make it more complex right there;
b) you create an expectation of reuse which will exercise your API and create a dependency or those relaxed choices so long ago
we are notably bad at anticipating change and usage. the way it will be consumed might not be that complex/often/be dropped. or it can be used in scenarios where the abstraction, the strategy put in place and the performance of your code may make it unsuitable for reuse too.
you will not anticipate how it will integrate for the second consumer. if you're just one, might not be worthwhile to do it now. you will do it for sure later if that time comes!
MOTIVATION
-
think of it as a response to "but I thought your codebase was decent" aka "wasn't that feature already developed"?
this can be useful for you as a developer, to find the pattern and question it. it can be useful as a manager too, to be more sensitive about the subject of code reuse and adjust your expectations
this is also a very prement subject in an age where we have languages as JS which run everywhere. I can't stress enough how THE LANGUAGE DOES NOT MAKE TO ENVIRONMENT. there are so many other variables at play.