Extreme Programming - Refactoring and shared libraries

Author

Refactoring and shared libraries

Steve Jorgensen

2004-03-19, 1:17 pm

So you get to a point where you realize that based on the projects you or your
team specializes in and your coding style, there are certain bits of
functionality in common between the projects, and that suggests a shared
library.

Now, when you decide what will be the plane of separation of concerns between
the code inside and outside of the library, you do it based on what makes
sense in the context of the existing projects. As luck always has it, in
spite of your best thinking when you created the library, the very next
project you try to apply it to suggests some significant refactoring across
the library API boundary.

There seem to be 2 options at this point: Fork the library, or refactor -all-
the projects that use it. How have others here handled this issue?

Paul Sinnett

2004-03-26, 11:50 pm

Steve Jorgensen wrote:
> So you get to a point where you realize that based on the projects you or your
> team specializes in and your coding style, there are certain bits of
> functionality in common between the projects, and that suggests a shared
> library.
>
> Now, when you decide what will be the plane of separation of concerns between
> the code inside and outside of the library, you do it based on what makes
> sense in the context of the existing projects. As luck always has it, in
> spite of your best thinking when you created the library, the very next
> project you try to apply it to suggests some significant refactoring across
> the library API boundary.
>
> There seem to be 2 options at this point: Fork the library, or refactor -all-
> the projects that use it. How have others here handled this issue?

I'd fork it first, and refactor later. It is easy to find duplicate code
in libraries with a common root. You might find it less work than
maintaining two projects while trying to develop a third.

Sponsored Links