[HN Gopher] Avoid rewriting a legacy system from scratch by stra...
___________________________________________________________________
Avoid rewriting a legacy system from scratch by strangling it
Author : ahuth
Score : 30 points
Date : 2020-02-17 20:55 UTC (2 hours ago)
(HTM) web link (understandlegacycode.com)
(TXT) w3m dump (understandlegacycode.com)
| noobermin wrote:
| Am I the only one in the IT adjacent world who thinks the inverse
| of this is the larger problem (churn, NIH, reinventing the wheel)
| in software today?
| dano wrote:
| No, you are not the only one. The quest for the new shiny thing
| is stronger than ever today. New frameworks, new languages,
| silver bullets everywhere. Good decision making frameworks are
| in tremendous need in the technology world to help everyone
| understand the ramifications of the choices they're trying to
| make.
| benignslime wrote:
| https://martinfowler.com/bliki/StranglerFigApplication.html
|
| If you wanted to read the referenced article. This was the first
| thing I thought of. I appreciate Fowler's writing style and his
| sourcing. He always links some interesting stuff.
| mannykannot wrote:
| One thing that complicates matters somewhat (as if they were not
| already complicated) is at the decision point marked
| _isRoundtrip?_ in the fourth (penultimate) diagram, where the
| affirmative case is handled within the new system.
|
| Given, however, what is being posited -- a legacy system that is
| not modular and which contains unrefactorable pathological
| dependencies -- the old system must also handle this case in
| parallel, in order to be in the correct state to handle future
| requests of a type that still need to be delegated to the old
| system.
|
| This parallel implementation may have to persist well into the
| replacement process, and the requirement for it to do so may mean
| that you still have to do double implementation of features and
| fixes for most of the transition.
| layer8 wrote:
| Of course, that approach is difficult to apply if the interface
| is a significant part of, or deeply entangled with, the pain
| points that the rewrite is intended to solve.
| msclrhd wrote:
| You can temporarily implement both interfaces where needed,
| create adaptors, or other patterns during the intermediate
| steps.
| layer8 wrote:
| Usually the problem is that you can't realistically change
| the interface, because too much other software relies on it,
| and having all that software rewritten would be too costly,
| and also risky. In addition, as a sibling mentions, the
| reason the old interface is a pain point is often that it
| exposes implementation details in a way that prevents you
| from rearchitecting the implementation. In that situation,
| adapters typically won't help.
| marczellm wrote:
| It is also difficult if there's an ill-defined interface that
| exposes implementation details, or no interface at all.
|
| It is also difficult to apply if we are not talking a
| server/client app but a desktop app, being rewritten in a
| different language or incompatible GUI toolkit.
| aargh_aargh wrote:
| The comma, present in the article and missing in HN, completely
| changes the meaning of the title.
| kspacewalk2 wrote:
| What is the alternative meaning? To be, the comma changes
| nothing. It's unambiguous either way.
| ummonk wrote:
| It can also be read as "avoid (rewriting a legacy system from
| scratch by strangling it)"
| [deleted]
| tapland wrote:
| I really don't get this. How does it change?
| [deleted]
___________________________________________________________________
(page generated 2020-02-17 23:00 UTC)