What should I do after get a legacy project?
Simple tooltip guide
Introduction
As Developers sometimes we take legacy projects. They’ve been written by (put somebody here) and due to the good Developers they are, they didn’t add any information about them.
So this little article shows or advice you a couple of tips about What should you do when you or your team getting a legacy project. It’s according to early project steps, it’s before you start to write code.
Read the readme file
[TIP] Some projects have a readme file between their files, so first of
all you must read it. It’s something like RTFM. This point can be obvious a bit, but a lot of people avoid to read the readme files.
What happens when a project doesn’t have a readme file?
[TIP] You can ask about the project to anyone familiar with it such as clients, co-workers, project managers, team, etc.
It’s important take notes about all that information because you must write a new readme file for the next developers who will take the project.
If you want a good reason for this, it’s time, time that you could devote to explain how to the project works.
[TIP] If you don’t have contact with any developer related to the project, you may do a review of similar projects for more information.
Next you’ll find a little explanation about Good Readme files.
Good readme file (my version)
Each project must have a readme file, but What information should I add?
- Basic information about the project like an introduction, answers to questions such as what is it? what do it?
- A bit information about the most important files in the project such as config files, database files.
- A readable list of steps for setting up the project.
- Links of interest.
- List of dependencies, or dependency file.
- How to contribute in it? Where should I add the bug?
- Code guidelines.
Examples of good readme file:
But, if the project is big with a lot of information, maybe you should think in a Wiki. Check this github link about wikis. An example of this:
Draw a domain model using UML
I know, do documentation is boring, but in this case is very important, it gives you a lot of information about the model and their relationships.
If you don’t know what a domain model is, check this info in wikipedia or you can also read those universitary books:
- Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development written by Craig Larman.
- UML Distilled: A Brief Guide to the Standard Object Modeling Language written by Martin Fowler
Play with the project
If you have finished to setting up the project, and you have a running local version, you may start to play.
Feel free to play with the project, you can complete its main feature.
Or you might try do it again with different workflows, trying to find errors or clues to new features that they should be analyzed.
Or you may check other secondary features.
The keynote of this is, take notes about it maybe you can use those notes for improve the readme file or write one or maybe for add any behavior not provided before or just for improve the project, I don’t know the options are unlimited.
Drive on the code
It could be a hard approach, but if you’re a good and experienced developer you could read the code.
It’s no fun reading something like this:
# app/models/topic.rb
class Topic < ActiveRecord::Basedef self.r_topics(questions)
rt = []
questions.each do |q|
topics = q.topics
topics.each {|t| if t.enabled?
rt << t }
end
endend
Is time to write some code?
For a ruby version check this article by Ezequiel Delpero about The most common mistake on legacy rails app
Further reading
- Clean Code by Robert C. Martin
