Not every developer is lucky enough to be involved in a project from the beginning. The developer is often entrusted with the support and further development of an old project.
It is a real blessing if you have one of the old developers ready at hand. But this is rarely the case. A project is usually “handed down” from one developer to another. The knowledge of the original author is no longer available, the code is outdated and there is no documentation – i. e. the developer has to work with Legacy Code.
So what do you do if you have to change Legacy Code but you don’t understand it?
I also needed to ask myself this question many a time. This article is intended to give you a few tips on how to address this problem. At the end of the article, you will find a short checklist and a particular useful piece of advice for your work with Legacy Code.
A good back-up is the most important thing if you want to change unknown code. Using unit tests will give you this back-up. However at first you do not create class tests for testing the behavior of single classes, but rather tests to ensure the fundamental behavior of the application.
If you change places in the code later on, these tests will ensure that you can recognize whether the fundamental behavior of your application has changed. Additionally, this will make you aware of previously unknown side effects. You will gain a better understanding of the code.
Using a version control is the next step to achieve more security. Nowadays, this should be a prerequisite for every development project, of course. Nevertheless it is worth mentioning because, psychologically, this is a very important issue for you – the developer. If you develop someone else’s project further, you will always take risks. That’s why you need the security to be able to restore an old executable version whenever you want.
Using a continuous integration server will be the next step. Every time you are saving new code with your version control, the continuous integration server should build the new version and run all tests automatically. As a result, you will always notice when a test fails.
While establishing your safety net, you have also acquired a basic understanding of the code base. But this basic understanding is often not sufficient to fulfill a specific task or to change the code.
For my part, I take notes when I reach this point. For doing this, I use the classic form of taking notes – pen and paper. This technique is particularly effective when you work with big classes. With the aid of my own pseudo-UML, I try to understand the dependencies of the different methods. And this also helps me visualizing the dependencies to other classes.
With the help of your notes, you can perform your first refactorings and gradually decipher the Legacy Code. While doing so, I consider whether the names of the methods really describe what the method does. If necessary, I adapt the method names.
Subsequently, I check whether the class or a method has to perform multiple tasks. I consider whether it is possible to transfer all methods belonging to one task into a separate class. This means, I try to improve the code structure.
My notes help me with this task, too. Besides, I often print the code out, mark sections in different colors and take notes on the printout.
While restructuring the code, I try to create class tests at the same time.
At the restructuring of the code, I try to create class tests parallel. Hence I increase my test coverage to gain more security; and I simultaneously benefit from a better understanding oft the code.
Finally, I clean my classes of dead code. For this task, I use the opportunities of my development environment – e. g. Eclipse. Only after this step I dare to develop new features.
This list summarizes the main points of this article. You can use these points as a checklist.
If you want to learn more about refactoring of legacy projects, I recommend the book [ WORKING EFFECTIVELY WITH LEGACY CODE BY FEATHERS, MICHAEL](AUTHOR)PAPERBACK
by Michael C. Feathers. This book offers a deep insight into this subject and there are many interesting lessons to be learned from it. covers really deep into this theme and you can learn a lot of. A very good book.
How do you get the security required for changing the source code?
How can you understand the code well enough to be able change it?
Sorry, this entry is only available in Deutsch.
Scrum is a development methodology for organizing projects in socially complex environments. Such environments are characterized by high dynamics, lots of dependencies and frequently changes.
Scrum is particularly popular in the field of agile software development. But what does agile software development actually mean and and why is scrum an agile methodology? This article tries to answer these questions.
In february 2001, Kent Beck, Ken Schwaber and other leading heads of the software development community met in Utah (US). To this day, Kent Beck plays a leading role in the field of Extreme Programming (XP) and Ken Schwager is one of the founders of Scrum.
At their meeting, they drafted the Agile Manifesto and what is today known as agile software development got its name.
The manifesto consists of four values to which the participants of the meeting feel committed.
Based on the agile manifesto, these four points have the following meaning in Scrum:
These four values are based on another 12 principles which remain as relevant as ever. They should guide the work of every agile software craftsman:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly
This post is about the Product Backlog. At first I would like to explain to you what the Product Backlog is. Than I will explain on which fundamentals the first User Stories will be based on. Because before the first Sprint can start, the Product Backlog must be filled with Stories.
In simple terms a Product Backlog is a list of all customer requirements. These requirements are drafted in so called User Stories and sorted by priority for the customer. The Product Owner is responsible for the Product Backlog as well as for the priorization.
You can read more about the responsibilities in Scrum in a past post of this blog: “Scrum -A Short Introduction”.
The Scrum Team take a set of User Stories from the Product Backlog for a Sprint. The Team puts these Stories in another backlog, the “Sprint Backlog”. This backlog contains the User Stories which will be implemented in a certain Sprint.
For selecting the User Stories, the Development Team is guided by the priorities given by the Product Owner.
Due to the fact that these Stories are already estimated at the time of selection, the team knows which Stories suit into a Sprint and which would blow the frame.
After the User Stories are selected, the Team will derive specific tasks from them. Let me explain this by using an example. An User Story for a new web solution might be: “As User I want to login to the server via password.” Based on this Story, the Team members find their specific development tasks, for example:
The Product Backlog is independently groomed from a Sprint. The Product Owner constantly inserts, updates and deletes Stories. This is his job.
In order to do this he is constantly in touch with the Scrum Master, the Development Team and with Customers. A Story is only ready for a Sprint Backlog if it is completely formulated, priorized and estimated by the Development Team.
Before the first Sprint starts, the Product Backlog needs to comprise some entries. The first entries are derived from the Product Vision and from the customers core requirements.
For further details on the Product Vision, I recommend to you the blog of Roman Pichler.
A Vision Board or requirement workshops with the customer offer good opportunities to find the main requirements of a new product . For more information on the Vision Board, please have a look at the blog of Roman Pichler again.
A requirement workshop is a meeting of a lot of parties involved, like the Product Owner, the Scrum Master, Team Members and Stakeholder. During such a meeting, User Stories are created on the basis of current developments in the fields of product concepts, marketing, sales etc.
Scrum is a development methodology from the field of agile software development. Some people describe Scrum as an agile management framework.
The scrum methodology divides software development into short, recurrent cycles – the so called Sprints. Development targets and results are reviewed, adjusted, discarded or redefined after every Sprint.
However, Scrum is no magic bullet against many well-known problems in the field of software development. If, for example, a software developer is poorly trained, there is nothing Scrum can do about it. Scrum only shows a new way to structure the software development process. It is the people involved who must break new ground.
Besides, Scrum requires a learning phase that is easily underestimated. You cannot master Scrum overnight.
Scrum works with flat hierarchies and encourages every developer and every person involved to assume responsibility.
The tree main roles of Scrum are the Product Owner, the Development Team and the Scrum Master.
The Product Owner represents the customer’s point of view. He is responsible for the final product. This responsibility manifests itself for example in the following tasks:
The Product Owner collects the requirements, from which the individual tasks of the team will be derived later on, in the so called Product Backlog.
There, the requirements will be phrased as so called User Stories. A User Story is a short, textual description of the feature to be developed.
The Development Team develops and realizes the Product Owner’s vision. The team members implement the requirements from the Product Backlog. But they don’t get their implementation tasks delegated in a conventional way. They rather work out the tasks themselves after discussions with the Product Owner and on the basis of the product vision.
A Development Team can consist of software architects, developers, testers and other specialists. However, it is important that the team members consider themselves a team and not a group of individual specialists.
The Scrum Master is comparable to a coach or a consultant. He guides the team and supports it in further developing its skills.
Scrum divides the development in short cycles, the Sprints. A Sprint has a predefined length of one to four weeks. At the beginning, the development goals to be achieved are determined in the so called Planning Meeting. Here, the Development Team and the Product Owner negotiate the scope of every development goal. The goals are derived from the User Stories in the Product Backlog.
During a Sprint, a daily status meeting, the Daily Scrum, is held. In this meeting, the developers report on their difficulties and define their own development goals, which will be implemented by the next Daily Scrum.
At the end of the Sprint a so called Review is held. The implemented results are handed over to the Product Owner and discussed.
After the Review, another meeting, the Retrospective will be held. Here the Scrum Master assists the team in analyzing the past Sprint. The own work and the own way of working as well as the environment are critically examined and areas of improvement are discussed. The results of this meeting will contribute to the new Sprint.
A new generation of my blog mueller-kunad.de is being created here. I’ve changed my provider and will use this as an opportunity to redesign my sites.
In the coming weeks, I will update my old articles and republish them piece by piece. Simultaneousely I will write new articles on agile software development, agile methods and Java programming. You will find articles on many things which cover my daily job as an agile craftsman.