-
Removing files should be relatively safe. If you miss any references your build system should fail, hopefully with the problem files if the tool is any good.
-
Removing scoped code can be done if all references to them are removed from within the scope. E.g. references to a local variable within a method or references to a function within a module.
-
Removing public functions, that are exported by a module or added to the global scope, cannot be done deterministically due to the dynamic nature of javascript. Try the following:
-
grep code base looking for method uses (Warning: may not catch all cases e.g.
myObj['method']()
ormyObj[getMethodName()]()
etc) -
grep code looking for the import of the containing module, then further grep to find method references:
grep -ril path/to/my/module www/src | xargs grep -ril myMethodName
If your project uses relative import paths, grep is not going to help much. You can use https://www.npmjs.com/package/madge to help get a list of files that depend on a given module. -
Deprecate the function by throwing an exception. The stack trace can be used to find modules that still depend on the function. If no errors are encountered by any of team/QA, remove in next sprint.
-
While deprecating a function, check the functions that it calls. They may also be deprecated.
-
Unit tests help a lot but cannot be 100% relied upon if:
-
coverage is poor - Cannot trust that tests cover all uses of method.
-
mocks are used heavily - If mocks of the method are used with pre-programmed behaviour, removing the method may not causes any changes in the tests. If a single stub is used, removing the stub should show errors where method is depended on[1].
-
-
Functional/acceptance tests should verify that existing functionality still works.
-
References:
[1] https://blog.8thlight.com/chris-jordan/2015/08/26/loosely-coupled-testing.html