Remaining sane in Legacy Projects
updated about 1 year ago; latest suggestion about 1 year ago
This proposal has been withdrawn...
We can run from them the whole life by starting new projects again and again, but, eventually, we'll end up with a legacy project. Whether it is a small pet-project, that "just-need-to-be-updated" or a huge enterprise monster with tons of dependencies, there'll be a legacy. The legacy will find us.
In this talk, we'll see how one can remain sane while working on the legacy project.
Why so Legacy?
Everyone knows that working on the legacy project can be really painful, so at first, we'll talk about how to avoid those projects at all. While every developer tends to call every project legacy and rewrite everything, sometimes it is hard for the developers to explain to non-developer-species why some specific project is a legacy in simple words. In outsourcing, an explanation with clear, understandable facts can help to avoid that kind of projects. So in this talk, we'll see how to quickly check an gather the facts about the current state of the project. This will help us in the decision whether the project should be taken in or not. Also, a quick check will allow us to understand which parts of the project we should concentrate the most.
I've got a Legacy project. What should I do immediately?
Next, we'll discuss some important steps which need to be done once a project was taken in. While these steps will work for any project, for legacy projects, you have a small window of time when these steps will work. I.e, talking to a person who wrote this project directly, can save us a lot of time.
How one can survive in Legacy with(out) rewriting
In the next part of the talk, we'll concentrate on the specific approaches on how to work with a legacy code in general. Here we'll cover such topics as "How should I change that big thing", "Should I rewrite this module", "How to write code that will be understood in the future". Here we'll also discuss things that should make a project "less-legacy".
In the final part of the talk, we'll see how to answer the question: "Are we better than developers who wrote this project before?"
@8b2f2d3e6553c2b4048b93300959895ab76b4154 well, yes. This part will be covered as well.
So what you mean is evolving an app over time without stopping all forward motion to rewrite it from the ground up?