Today I lost a method that I was using since my co-worker redefined it to take its superclass instead. So after synchronizing with the repository I had trouble. Would it had been better in this case to use some annotation like @Deprecated instead of removing the method so that I would get an error message telling my that the method was deprecated? Can a version control system or an IDE work around situations like this by deprecating methods instead of deleting them?
1
@Deprecated annotation is the correct thing to do. Removing code creates breaking changes in the API that is being used – this can be bad.
The thing is that often people ignore the ‘bad’ thing and still use deprecated methods because it doesn’t fail the build. Thus, the next correct thing to do is to make using deprecated methods fail the build.
It is possible to make the build scripts often used by Java developers to fail the build on compiler warnings (not only errors). There are various approaches to doing this depending on the build system being used (gradle, maven, ant, …).
At the point that you now fail the build when (unconsciously) using the deprecated method (you upgraded the library, something is now deprecated, the build fails – this is a good thing).
At that point, you can specifically disable deprecated warning for that method call with @SuppressWarnings( "deprecation" ) and then it will build again. But now you know that you need to fix that code, because your build failed and that alerted you to the changing API.
For Java, I’m not sure the specifics of deprecation beyond the @Deprecated annotation. To answer your question, I am not aware of Git at least being able to adequately and clearly deprecate methods themselves (I may have not come into contact with them). In my experience, wholesale removing methods may be a bad idea, as you yourself were used to using them; annotating a class as @Deprecated may help in the transition period to the new build so all team members can clearly see where that method has gone and why. Commenting the annotation as to when, why and how the method has been deprecated may be a good idea too.
Deprecation is not designed for within a single project in a team environment; it’s designed for published APIs. Within a single project, it’s can be useful as shown in Mothermole1’s answer to indicate that there is a better way of using that API now. This question has some suggestions on how to properly document why the method/class was deprecated and what should be used as an alternative.
I’d be interested to learn some more about the circumstances under which the offending method was removed. In my mind the length of time that code has been around and how core it is to the app determines how much ceremony should be attached to its removal. If it’s used in one other place and is fairly new, I wouldn’t expect any process for its removal. However, if it’s been around for years and is part of a core class that is used throughout the app, I would expect some discussion as to how to best handle the transition.
There are a couple ways to do that. If the method in question is part of a public API that is exported outside the app, the best way is usually to deprecate the method in one release and then remove it in the next. Often for backwards compatibility you might never remove the method; you would just make it clear that it isn’t supported anymore. In an internal API, depending on how pervasive the use is and how complex it is to change I’d just remove it and fix all the callers. In cases where the call is used in many places and is difficult to change deprecation is probably a safer bet – just be sure to recognize the technical debt you may be adding to the project since you’ll now have two different ways of doing things. You may want to consider a migration strategy in which you would transition the code over a longer period of time.
1