The reusability fallacy – Part 3

89 点作者 galaktor大约 5 年前

9 条评论

ivanbakel大约 5 年前

>The latest paradigm “Microservices” became popular in the mid 2010s.Microservices isn't for re-usability. It's main benefit is better encapsulation, which should let you do independent resource management/deployments/failures.>If we look at reusability, we notice that this is the tightest form of coupling possible: If the reused part is not available, the reusing part cannot complete its work by definition.What? This is a weird nothing-burger of a sentence. Why can't multiple components re-use some resource without gracefully handling any failures? Why does re-usability mean "cascading failures by design"?>An important property of reuse is that the reusing part ... does not work without the reused asset ... The reused functionality is an integral part of the solution that (re-)uses it.Oh, I see: because the author has defined it this way. Then the article goes on to try to argue a semantic difference between "usability" and "re-usability", in that usable components can be re-used independently, but in a way that can gracefully fail! So the whole thing is just begging the question.There's no argument here as to why I can't write a distributed component with an eye to it being re-used in the future. There is no criticism of re-use in distributed systems. The only criticism is of tight coupling, which is totally valid, and then saying that re-use demands tight coupling, which is not substantiated.

评论 #22720232 未加载

评论 #22712756 未加载

评论 #22713031 未加载

评论 #22712880 未加载

discreteevent大约 5 年前

Szyperski also said this back in 1997. "Maximizing reuse minimizes use"<a href="https://books.google.ie/books?id=U896iwmtiagC&pg=PA45&lpg=PA45&dq=maximize+reuse+minimise+use+szyperski&source=bl&ots=FH0S7vrsaI&sig=ACfU3U1xIujcH8XOMiFlg7lXUWS4KHaR7g&hl=en&sa=X&ved=2ahUKEwiU7ufNyr3oAhVKSBUIHaXgBxEQ6AEwCnoECAUQAQ#v=onepage&q=maximize%20reuse%20minimise%20use%20szyperski&f=false" rel="nofollow">https://books.google.ie/books?id=U896iwmtiagC&pg=PA45&lpg=PA...</a>

galaktor大约 5 年前

Part 1: <a href="https://www.ufried.com/blog/reusability_fallacy_1/" rel="nofollow">https://www.ufried.com/blog/reusability_fallacy_1/</a>Part 2: <a href="https://www.ufried.com/blog/reusability_fallacy_2/" rel="nofollow">https://www.ufried.com/blog/reusability_fallacy_2/</a>Part 1 was posted previously but without much discussion: <a href="https://news.ycombinator.com/item?id=22583605" rel="nofollow">https://news.ycombinator.com/item?id=22583605</a>

whack大约 5 年前

The "fallacy" breaks down pretty quickly when we consider its implications. If we were to follow the suggestions given, we shouldn't be using:- Email services such as SES or Sendgrid- Password auth services such as Firebase- Chat services such as TwilioYou might say those are extreme examples, and that's the whole point. Clearly there are a ton of use-cases where it makes sense to build reusable services once, and using it across many clients. Not just for "enhancements", but as an integral part of your service's functionality. So how and where do we draw the line between reusable services and avoiding service-dependencies? That's the real question we should be asking, and one I don't see being answered in the article.

评论 #22714850 未加载

评论 #22713803 未加载

评论 #22715724 未加载

danielovichdk大约 5 年前

I think about reuse in a couple of different ways.I do not copy paste the same exact code multiple places. Then i use the same code.If the code is not exactly the same, it's not a copy, hence it's not up reuse.I do not generalize code before 3rd strike and refactor can be applied, and then I still use a lot of time thinking if it might a premature optimization.I write microservices the same way as i write methods. If i copy and paste the exact same microservice, it might be up for reuse (3 strikes). If it's reuse, the same specifics applies as when programming a method or type.I would never ever write any new code with reuse in mind. It's arrogant to think one can forsee the future, and that's exactly what writing for rejse is about. Start small, evolve.

nikanj大约 5 年前

Java has the opposite problem. One of the often repeated taglines is "If you're unhappy with X, you can easily replace it with Y, Z, or Q!"I just want one well-working thing, not twenty alternatives - seven of which turn out to be abandoned, three incomplete, one only works with Java 15 beta, and two are actually forks of the same abandoned pre-Oracle blogpost from Sun.

评论 #22715548 未加载

6510大约 5 年前

Like my own his English is good but not that good. His seems the right way to explain (there probably is a formal description for the style of writing (and a word for it in German)) but when reception is not guaranteed (I keep feeling like I almost got his point.) I would lower myself to explaining by code example. Something like a "hello world" of usable vs re-usable. Someone more skilled in the art should probably address note 6 ( <a href="https://www.ufried.com/blog/reusability_fallacy_3/#fn:6" rel="nofollow">https://www.ufried.com/blog/reusability_fallacy_3/#fn:6</a> )I did recall a thought I had some years ago that I will describe crudely because I'm lazy:Parts of applications, by popularity, should be re-implemented in API's.Parts of API's, by popularity, should be implemented in modules.Parts of modules, by popularity, should be implemented in frameworks.Parts of frameworks, by popularity, should be implemented in (higher) languages (then lower)Parts of languages, by popularity, should be baked into hardware.(Unpopular parts should migrate the other way around but that is not important right now)

galaxyLogic大约 5 年前

What do we mean by "software reuse"? I propose this definition: Software reuse happens whenever a given piece of code is called from more than one other code-location.That means whenever a function has more than one caller we have reuse. Or when a web-service request is created from more than one code-location, we have reuse.Is there an official definition for what "software reuse" means?

m3kw9大约 5 年前

From my experience actual good reusable code are very small and usually relatively simple great specialized task. As the component get more features, and when you use it, you are in a trade off situation where this works, but it doesn’t fully do exactly what the requirement needs orbit does way more than it needs