Yeah, you read that right. We’re gonna break some rules!
I ran across an interesting scenario at work today that I think merits some discussion. In this post, I’ll cover what DRY is, and when following it religiously may actually cause problems.
Today we’re going to talk about breaking changes in libraries. Specifically, we’re going to answer the following:
- What constitutes a breaking change?
- How can I avoid making breaking changes?
- When is a breaking change a good idea?
- How do I indicate that a new version contains a breaking change?
You found it! After many hours of scouring the internet, you’ve finally discovered the library that does precisely what you need. Except… it has a dependency… on a package that your architect has declared unfit for your company. Continue reading “Eliminating Hard Dependencies”
In the last post we discussed why it could be preferred to expose all of your methods publicly. However, I deliberately left something out. Some of you may have noticed. Continue reading “Hide Your Secrets”
Before we get into today’s topic, I have some sadness to report. My beloved Dallas Stars were eliminated from the NHL playoffs. Also, my favorite player, Trevor Daley, who now plays for the Pittsburgh Penguins, has suffered a broken ankle and will not be able to play in the Stanley Cup games. Happily, if the Penguins win the Cup, he’ll still get his name engraved on its holy base!
Anyway, enough of that. Let’s get on to software.
Last time we built a very simple pluggable program where each plugin provides a translation of the string
Hello, World! Today, we’re going to explore some of the problems inherent in our approach. Continue reading “Handling Errors from Plug-ins”