In my work I often see people writing library code (A) that "wraps" and "simplifies" use of another library (B). When I see this it immediately makes me think:
- The person who wrote the (A) automatically assumed (B) was going to be too hard to use.
- They Google'd some feature they were looking for and found (A) supported it. But (A) supported lots more besides, so (A) did not look exactly like what they had imagined.
- They did not bother to learn how to use (A) properly, before then creating an application using (A).
- Instead they learned to use (A) by creating a wrapper (B).
- Does (B) add any value - simplifying is not value.
- There is this idea that if you keep abstracting the final application that "joins them together" will somehow write itself.
- Creating re-useable libraries is what good programmers do. I am a good programmer -> I must create some libraries.
- If I had written (A) I would have done it more like (B).
- (B) Provides a "layer of indirection" allowing me to choose to swap (A) for an alternative library (C) one day in the future.
- Writing (B) makes you look busy while you deliver the work of (A) wrapped up with your name on it. It's basically plagiarism!
But (B) just introduces more maintenance? Worse still it makes maintenance harder while developers pick through unnecessary "proxy" and "interface classes".
Why not simply write an app that uses a subset of (A) directly?
To me it smacks of a work avoidance technique. Rather than think about how to address a customers problems, or stick your neck out and make a bet on a library... it's easier to write an abstraction layer, which will allegedly "make it easier" to write the business app one day in the future.
No comments:
Post a Comment