- Classical: Code that relates to something which is no longer supported.
- Modern: (1) source code inherited from someone else and (2) source code inherited from an older version of the software.
(3) BOTH Trifecta
-
Inherited from someone else: Employee who built can't work on it anymore.
-
Older version of software: Employee quit or Source code bought from someone else.
-
3rd: Time. Source code can migrate from being just technical debt to being hard enough to understand / refactor that it is arguably legacy code.
-
Bonus: Software integrations (could maybe skip this).
- Documentation or readable code
- Architecture and planning
- DDD (domain driven design)
- Clear vision
- More senior developers?
- Agile practices?
- Refactoring.
Roughly: Experience and giving a damn.
- concede: planning is hard
- rapid iteration
- 1-4. add features. 5. refactor. 6. repeat.
- features use existing features. (ossify)
- Holistic refactoring is hard in practice.
- Bonus: Green fields
Our turn to agile practices, especially rapid iteration is to deal with the fact that planning out software early on is in fact hard, and so adding features short at a time and then going back to refactor them is a more realistic approach. Assuming the refactoring actually happens.
This also deals with legacy code in that it it encapsulates it into discrete parts of the software, however in practice of course any new feature uses existing features and so if you have messed up your abstractions between the features you are up shit creek, and have just ossified the legacy even more.
Also the concept of holistic refactoring is almost a non-starter, in fact some advocate green fielding instead of even attempting a holistic refactor. aka, keep adding features for a few years, doing minor refactors as necessary, then when it becomes wildly untenable, look at the whole system and rewrite it from scratch.
I would argue that integrations can be legacy, but here your options of fixing them are low, since you don't control the codebase. If your system integrates with it and depends on it, it is legacy. Otherwise it is not.
This is why a lot of developers are pretty cautious with integrations. If our definition of legacy code is code which we are scared to change, either due to work involved or difficulty, perhaps due to not having the develops hired that built it in the first place.
They have a bad tendency of ossifying into immutable objects that would be a nightmare to refactor.
-
Monolith is a bunch of services in one spot.
-
Micro services mean you split up each service, making a clear interface between each one.
- You trade complexity between services in the monolith between very well defined services for a ton of work on the interfaces between the micro services.
-
Using micro services early as a way to avoid legacy is a horrible idea.
-
As an aside: I am heavily in favor of going the mono route and breaking out well defined micro services only when you are 1. absolutely sure it is a stable well defined service and 2. you need it for some kind of scaling reasons.
Holistic refactoring is tricky for a team. refactoring is always tricky to get buy in from business side. Business side and how modern agile software is built is a tricky relationship as is. The companies that are really succeeding with their software are letting the engineering dictate the business and hoping the payoff will happen. fight me.