Deprecated Code: How Dependency Mapping Can Prevent Headaches
What is deprecated code?
Deprecated code (sometimes called “dead code”) is the equivalent of a sticky note saying “this will be removed in the future” on targeted parts of code. The code can’t be removed immediately because consumers of that method or class still need that section to function.
Often, removing dependencies on deprecated code is not a priority for development teams that prefer to focus on new development. However, unaddressed deprecated code can lead to future code breaks and inefficient databases.
It’s important to note that deprecated code and obsolete code are two different things. Deprecated code generally continues to be used for legacy functionality, and the dependence is removed during a big release. Obsolete code, on the other hand, is already out of use. For example, the .NET framework marks a type or member type that is obsolete as “ObsoleteAttribute.”
A Part of Software Evolution
Deprecated code is a natural part of software’s evolution—and any engineer’s list of pending tasks. As new code is written and legacy code updated, some parts will become outdated and will need to be removed down the line. Typically, deprecated code occurs when code has been replaced with an alternative method or class—and it almost always occurs in a shared library.
While deprecated code is common in development cycles, how does it impact software engineers? And how can dependency mapping alleviate the complications inherent with deprecated code? We take a look below.
Why remove the dependence on deprecated code?
Many organizations consider deprecated code to be a ticking time bomb. The deprecation is most often by someone building a library on a different team in the organization or a 3rd party.
For example, if we upgrade to a new version of Log4j, we might see this in the release notes:
The team would need to replace LoggerConfig.getProperties() with LoggerConfig.getPropertiesList() and change the code to handle a List not a Map. The “time bomb” is that one day the team will need to implement a new version of Log4j and getProperties() won’t be there anymore. If teams upgrade before handling the deprecation, the software won’t compile, keeping the team from moving and taking on new features, better performance, and security improvements.
Additionally, there might be security problems fixed by a new upgrade. If that’s the case, teams might need to move to a new version quickly. If teams naively moved to a new version before removing the dependence on the deprecation, the changes that weren’t made before will have to be made before the security problem can be resolved.
The benefits of removing the dependence on deprecated code include:
- engineers can streamline searches across applications that an architect or other technical leader may need;
- not having to dig through build logs for multiple projects;
- keeping teams up to date;
- upgrading newer libraries taking advantage of security improvements and new functionality.
Does deprecated code cause issues?
Removing the dependence on deprecated code is good housekeeping. Teams that want to take advantage of a new version of a service or library will likely want to remove dependencies on the full scope of deprecated code, but doing so without a full overview of what that code connects to could result in widespread breaks. Teams then have to spend large amounts of time retroactively fixing breaks—which may delay any planned launches.
Engineers may receive warnings about removing the dependence on deprecated code, but these can be easy to dismiss in the moment. Warnings don’t convey the full extent of the change on the overall code and they don’t inform engineers of the downstream consequences.
Engineers know that at some point the dependence on deprecated code will have to be removed. So in some cases, they are swayed to get rid of it hastily rather than fully understand all of the connected dependencies that can in turn cause other code to break.
How does CodeLogic and dependency mapping help?
Today, engineers manually search for references to deprecated methods within a package or project using a simple text search. This option, however, doesn’t detect all the deprecated code, especially if engineers don’t know the specific code that is deprecated.
Rather than working with an incomplete picture, engineers need to identify all connections linked to the deprecated code. Dependency mapping provides dev teams with a full picture of their software connections so they can understand the full scope of their application landscape and analyze down to the data layer.
The CodeLogic dependency mapping dashboard displays data for the following categories:
- Inventory of classes, methods, database tables, columns, and foreign keys
- Code complexity score
- Trend line
- Class and method analysis
CodeLogic’s class and method analysis reveals the classes and methods in a given application that have a high volume of software dependencies. Using this as a measure of code complexity and risk, CodeLogic data can be analyzed further to see the number of inbound relationships, as well as all other application connections that rely on the deprecated code.
Deprecated code doesn’t have to be a lingering task or a huge undertaking. Using dependency mapping, teams can quickly and efficiently identify deprecated code and begin phasing out the dependence, ensuring minimum disruption to workflows. Dependency mapping eases the process and mitigates risk, so that engineers can focus on more constructive projects.
If you’d like to see how CodeLogic’s dependency mapping can accelerate your deprecated code cleanup, request a demo.