Dont Refactor Published Interfaces Mercilessly

From RefactorMercilessly

Unfortunately, RefactorMercilessly (and some of the other ExtremeProgramming methods) does not seem like a good match when you're an OperatingSystem or ToolsAndLibraries? vendor. Once you have a shipping library that third parties depend on, BinaryCompatibility becomes an essential goal, and the FragileBinaryInterfaceProblem becomes your enemy. Note that all languages that let a derived class expose anything from a base interface/class suffer from some form of ModuleDependencyProblem, although some (C++) more than others (SmallTalk).

See PublishedInterface

Also, trying to write complete UnitTests for an OS or library would mean that you actually implement all the applications that third parties would implement, and verify that it is possible and runs with good performance.

Thus, I can see how this all would work for something like an end-of-the-line application on which nothing else has binary dependencies, but it seems less well adapted to other kinds of development. Unfortunately, when you are earlier in the food chain, an error affects so many more people (ALL the users of ALL the applications using your library).

Also, trying to write complete UnitTests for an OS or library would mean that you actually implement all the applications that third parties would implement, and verify that it is possible and runs with good performance.

I don't see this at all. UnitTests are discrete tests of interface members. How does this require you to figure out every possible use of your framework or library? Without UnitTests, you have to wait for the 3rd party to tell you about bugs in your interfaces. Very bad. -- RobertDiFalco

I think you are confusing UnitTests with user tests. A UnitTest doesn't know it's testing an OS. They are much lower level and fine grained. It tests that given certain inputs (valid or not), you get an expected output. Also I don't think units test have anything to do with performance.

Under ExtremeProgramming, if your end-users are programmers who buy a library, then your OnsiteCustomer is a programmer responsible for declaring an interface. Your CustomerTests will be specifications for an API and its features. Any "refactoring" which breaks these tests should not be ContinuousIntegration-ed. Hence the entire idea that "RefactorMercilessly" is somehow not compatible with this or that field is an idea that neglects XP's checks and balances. --PhlIp

This is a strawman argument. One does not refactor interfaces, one refactors code while maintaining the interfaces. This is part of the basic definition of refactoring. "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves the internal structure." [Martin Fowler, Refactoring Improving the Design of Existing Code p. xvi.] Refactoring is a disciplined way to clean up code without breaking things, anyone who is blindly changing interfaces is not refactoring, just playing. Refactoring mercilessly does not endanger interfaces, it protects them.