Changing code is a complicated task, there are ways we can come up to make the code extremely difficult to read for other developers on the other hand there is also ways to make it easier for future developers to understand.
But why do we change software ?
four main reasons.
- adding features,
- fixing a bug
- improving the design
- optimizing resources
Adding features and fixing a bug are only different in which point of view you are looking at it, for the customer something trivial may be a bug because he dosnt want it that way but for developers it may mean a new feature, never the less they have the same basic mechanic, we change the behavior in our application.
Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.
The act of improving design without changing its behavior is called refactoring. The idea behind refactoring is that we can make software more maintainable without changing behavior if we write tests to make sure that existing behavior doesn’t change and take small steps to verify that all along the process.
Optimization is the same as improving the design only with a different goal, we want to make the resource of a program low being this time or memory.
In general, three different things can change when we do work in a system:
- structure,
- functionality,
- and resource usage.
Preserving existing behavior is one of the largest challenges in software development. Even when we are changing primary features, we often have very large areas of behavior that we have to preserve.
Risky change
To make good code we have to embrace change, if we avoid making new classes, making or new methods then the current ones are gonna get bigger and larger to the point where they became imposible to understand.
Another advantage that comes with changing code is that we get better developers, experienced developers that are not afraid of doing code changes and making changes with good insight of the code make it easier to maintain a team that knows what they are making.
Reference
Michael, C. (2008). Feathers. Working Effectively with Legacy Code.
