4 ms·

The codebase of an internal system our team inherited is pretty old (14 years) and large, and there's a feeling a lot of the stuff is unused (dead code or unuse

by kgeist 4y ago

The codebase of an internal system our team inherited is pretty old (14 years) and large, and there's a feeling a lot of the stuff is unused (dead code or unused ancient features) and can be deleted. Fortunately, it's a monolith and all that matters is HTTP endpoints defined in a few config files. So we've made a script which downloads all access logs from the live server for the last 3 months and tries to find endpoints with zero or very low usage (it did find quite a few unused or rarely used endpoints). I'm planning the second step to be a script which builds a dependency graph and finds everything which is only reachable from unused endpoints. I wanted it to be a one-time endeavor but this blog post made me think it should be run on a regular basis.

jiggawatts 4y ago
I wonder if APM performance traces could be used to determine unused code paths. A lot of these tools sample stack traces at intervals, collecting statistics of how often functions are used. If you had enough samples, then with very high confidence you could find code paths that are never used in production.
- emptysea 4y ago
  Another option is tail based sampling which allows you to make the choice at the end of the request whether to keep the trace. With that you could configure the APM to keep the first $N traces for all endpoints and then start sampling after that
- chrnola 4y ago
  That’s an interesting idea! Reminds me of how Pyroscope’s continuous profiling data can be linked to OpenTelemetry traces[1]. [1]: https://pyroscope.io/docs/java-tracing/ https://pyroscope.io/docs/java-tracing/
kortilla 4y ago
Be very careful using this methodology. This is how you end up deleting stuff only called in rare but critical cases: - during outage - at end of year - during audits - when the one special customer that paid a fortune for an obscure feature decides to use it It might be the case that none of this applies to your application, but it’s why “check what got hit recently” (3 months is an eye blink in the business and govt world) is dangerous.
- tantalor 4y ago
  Any important enough would be automatically tested daily, in a prod-like environment, and/or at release time, with humans on call
  - ukuina 4y ago
    That seems an ambitious expectation for a 14-year old system.
  - deleted 4y ago
    [deleted]
- am1n0 4y ago
  This is why some sort of blacklist feature should exist to ignore such critical cases that are not intended to be deleted (but then again this defeats the purpose of the methodology).
  - ishan28mkip 4y ago
    This feature would then be abused by everyone and making the deletion script useless.
- kgeist 4y ago
  It's an internal tool, so if we delete something actually used by accident, they will let us know via the support desk or by visiting our office :) Sure it's dangerous but the code will still be there in git history, so it can be reverted, it's not deleted permanently. We're not planning to delete data. Before me, there was already an experiment when they modified code on a few pages to always return an error, to see if someone would complain - and no one did. In any case, there will be a human in the loop to double-check HTTP endpoints suggested for removal.
  - tasuki 4y ago
    To add to that, it might be a net benefit to remove unused code even if it ends up breaking something for someone for a while. This endeavour probably won't advance your career much, but making one's co-workers lives easier is worthwhile too!
ly3xqhl8g9 4y ago
Seems a good methodology, a caveat would be the deletion should start in coeff * 14 years from time of watch start, where coeff is a project complexity coefficient. If the watcher doesn't see a part of code called in another coeff * 14 years, then it's probably safe to delete it.
eitland 4y ago
Happy to see someone applying some science to our field instead of just going with a hunch. That said, as kortilla already mentioned, in most cases 3 months is too short time to get a complete answer. IIRC "Principles of Network and System Administration" by Mark Burgess has more about it, but intuitively you have to look for the largest cycles that exist, but there is also, again as mentioned by kortilla, events that doesn't happen on a schedule. One thing I try to do is, when I come across code that I have to research is to write down in the documentation for the function (Javadoc or similar) why it exist and the conditions when it can be deleted. You can also try to add some instrumentation code that notifies you when something is called. That way you can end up like me who, every new years day get a weird sms message at 14:00 or 14:01 from a system that no one can find, but at least I know that some system I cannot remember anymore still runs somewhere :-)

by kgeist 4y ago

jiggawatts 4y ago

I wonder if APM performance traces could be used to determine unused code paths. A lot of these tools sample stack traces at intervals, collecting statistics of how often functions are used. If you had enough samples, then with very high confidence you could find code paths that are never used in production.

emptysea 4y ago
Another option is tail based sampling which allows you to make the choice at the end of the request whether to keep the trace. With that you could configure the APM to keep the first $N traces for all endpoints and then start sampling after that
chrnola 4y ago
That’s an interesting idea! Reminds me of how Pyroscope’s continuous profiling data can be linked to OpenTelemetry traces[1]. [1]: https://pyroscope.io/docs/java-tracing/ https://pyroscope.io/docs/java-tracing/

kortilla 4y ago

Be very careful using this methodology. This is how you end up deleting stuff only called in rare but critical cases: - during outage - at end of year - during audits - when the one special customer that paid a fortune for an obscure feature decides to use it It might be the case that none of this applies to your application, but it’s why “check what got hit recently” (3 months is an eye blink in the business and govt world) is dangerous.

tantalor 4y ago
Any important enough would be automatically tested daily, in a prod-like environment, and/or at release time, with humans on call
- ukuina 4y ago
  That seems an ambitious expectation for a 14-year old system.
- deleted 4y ago
  [deleted]
am1n0 4y ago
This is why some sort of blacklist feature should exist to ignore such critical cases that are not intended to be deleted (but then again this defeats the purpose of the methodology).
- ishan28mkip 4y ago
  This feature would then be abused by everyone and making the deletion script useless.
kgeist 4y ago
It's an internal tool, so if we delete something actually used by accident, they will let us know via the support desk or by visiting our office :) Sure it's dangerous but the code will still be there in git history, so it can be reverted, it's not deleted permanently. We're not planning to delete data. Before me, there was already an experiment when they modified code on a few pages to always return an error, to see if someone would complain - and no one did. In any case, there will be a human in the loop to double-check HTTP endpoints suggested for removal.
- tasuki 4y ago
  To add to that, it might be a net benefit to remove unused code even if it ends up breaking something for someone for a while. This endeavour probably won't advance your career much, but making one's co-workers lives easier is worthwhile too!

ly3xqhl8g9 4y ago

Seems a good methodology, a caveat would be the deletion should start in coeff * 14 years from time of watch start, where coeff is a project complexity coefficient. If the watcher doesn't see a part of code called in another coeff * 14 years, then it's probably safe to delete it.

eitland 4y ago

Happy to see someone applying some science to our field instead of just going with a hunch. That said, as kortilla already mentioned, in most cases 3 months is too short time to get a complete answer. IIRC "Principles of Network and System Administration" by Mark Burgess has more about it, but intuitively you have to look for the largest cycles that exist, but there is also, again as mentioned by kortilla, events that doesn't happen on a schedule. One thing I try to do is, when I come across code that I have to research is to write down in the documentation for the function (Javadoc or similar) why it exist and the conditions when it can be deleted. You can also try to add some instrumentation code that notifies you when something is called. That way you can end up like me who, every new years day get a weird sms message at 14:00 or 14:01 from a system that no one can find, but at least I know that some system I cannot remember anymore still runs somewhere :-)