4 ms·

I think reusability is something that comes with practice. And I'm starting to think that "write once, reuse forever (without modifications)" is just a pipe dre

by dceddia 11y ago

I think reusability is something that comes with practice. And I'm starting to think that "write once, reuse forever (without modifications)" is just a pipe dream. Lately I've been realizing how easy it is to fall into the "abstraction trap". It's exactly your situation: I have a Thing. I need a new Thing that's slightly different, but I don't want to copy all the code! That's not DRY! It's paralyzing. So instead of duplicating code I spend time trying to tweak Thing, passing in parameters, adding special rendering cases, and finally it works as Thing and a smaller Thing2. But it's a mess, and it's not factored well, and it'll be a nightmare when Thing3 comes along. Check out this article from the other day: http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to http://programmingisterrible.com/post/139222674273/write-cod... In line with his idea of copy-pasting code, I think that's the way to go: copy all the code from Product, paste it into ProductThumbnail, and make it work. THEN refactor it, and pull out reusable bits... or compose the two somehow... etc.

janpieterz 11y ago
I think the flow you write should always be the way you work with code. First make sure it works, then look how to improve it, what parts are expressing similar behavior, what parts are different etc. If I remember correctly this is also what Robert Martin advises in Clean Code [1]. And it makes sense, worrying too much over what the abstractions are going to be is only going to slow you down. I normally go even a bit further (certainly on the frontend) and leave duplication until I wrote something 3 or 4 times (or until it has stayed there for a little while). This ensures that when I do write my abstracted component I'm actually making sure it is something that can, at least within that app, be re-used. I do re-use React components between different projects but am also using the same Bootstrap theme so this makes a lot of components really easy to re-use. [1]: https://www.goodreads.com/book/show/3735293-clean-code https://www.goodreads.com/book/show/3735293-clean-code

by dceddia 11y ago

janpieterz 11y ago

I think the flow you write should always be the way you work with code. First make sure it works, then look how to improve it, what parts are expressing similar behavior, what parts are different etc. If I remember correctly this is also what Robert Martin advises in Clean Code [1]. And it makes sense, worrying too much over what the abstractions are going to be is only going to slow you down. I normally go even a bit further (certainly on the frontend) and leave duplication until I wrote something 3 or 4 times (or until it has stayed there for a little while). This ensures that when I do write my abstracted component I'm actually making sure it is something that can, at least within that app, be re-used. I do re-use React components between different projects but am also using the same Bootstrap theme so this makes a lot of components really easy to re-use. [1]: https://www.goodreads.com/book/show/3735293-clean-code https://www.goodreads.com/book/show/3735293-clean-code