如果它坏了那就很好

最新推荐文章于 2024-10-03 09:02:12 发布

weixin_26748921

最新推荐文章于 2024-10-03 09:02:12 发布

阅读量95

点赞数

文章标签： python java

原文链接：https://medium.com/swlh/if-it-breaks-then-were-good-2092cf054123

版权

Let me tell you a story.

让我告诉你一个故事。

Once upon a time, there was a brave warrior named Devel Oper. This brave warrior had seen enough corruption in the kingdom he was serving, and decided to burn it to ashes (with the collaboration of his fellowship Cod’er and Tec Hlead) and start over. It wouldn’t be pretty, it would take them time, but this new kingdom would be more respectful, safe and… modular?

曾几何时，有个勇敢的战士叫德维尔·奥珀(Devel Oper)。这位勇敢的战士在他所服务的王国中已经看到了足够多的腐败，并决定将其烧成灰烬(在他的团契科德和泰德·赫利德的合作下)并重新开始。它不是很漂亮，会花费他们一些时间，但是这个新王国将更加受人尊敬，安全和…模块化？

A handful of us (sadly, not everyone can take company time for such an endeavour) have found ourselves improving the codebase. And probably not a single one of these refactors was blissful and without any trouble. Classes, that break? Sure. Are arguments no longer available? Uh-huh. Are dependencies no longer satisfiable? Tell me more.

我们中的少数人(不幸的是，并不是每个人都可以花些时间在公司上进行这样的努力)已经发现自己正在改进代码库。这些重构中可能没有一个是幸福的，没有任何麻烦。上课，那休息？当然。争论不再可用了吗？嗯。依赖关系不再令人满意吗？告诉我更多。

Is it bad? Well, yes. Is it good? Also yes.

不好吗嗯，是。好吗？也可以

如果坏了，那就早点好 (If it broke, then better sooner than later)

Image for post — Photo by Icons8 Team on Unsplash

It is okay to break a thing in a controlled way (that is, during a refactor), rather than finding it out via your customers. When something breaks, there’s a reason underneath, but you haven’t seen it yet. Have two classes vaguely named the same way, with roughly the same fields. Require it as an argument for one class, pass it as an untyped object to another class, let this other class cast again, but mistype the dependency. In most cases, it could work flawlessly… until you ask for the field that’s not there.

可以以受控的方式(即在重构期间)破坏事物，而不是通过客户发现事物。发生故障时，下面有一个原因，但您尚未看到它。有两个类的名称大致相同，方式大致相同。要求将其作为一个类的参数，将其作为未类型化的对象传递给另一类，让该另一类再次进行转换，但键入错误的依赖项。在大多数情况下，它可以完美工作……直到您要求的字段不存在为止。

When you refactored that (maybe moving it into a different module, maybe renaming a few classes, simplifying them who knows), something could break out of the blue, and it would be catastrophic, except that you found it in your own computer, and not on an error log worth millions.

当您进行重构时(可能将其移至其他模块中，可能重命名了几个类，简化了所知道的类)，某些事情可能会突如其来，除非您在自己的计算机上找到它，否则这将是灾难性的。不在价值数百万的错误日志中。

如果坏了，那就太耦合了 (If it broke, it was too coupled)

Why do some things break? Because some code requires too much of another. It is a classic that you notice during a refactor, that a business logic class depends on a UI data transfer object. We can imagine it the other way at some point, but why should the domain logic furiously need something from the UI, without even processing it in any single way?

为什么有些东西坏了？因为某些代码需要太多其他代码。您在重构期间会注意到，业务逻辑类依赖于UI数据传输对象，这是经典之作。我们可以在某个时候以另一种方式想象它，但是为什么域逻辑疯狂地需要UI中的某些东西，甚至没有以任何单一方式对其进行处理？

The same happens when two code blocks with very different goals (for instance, authentication code and data visualization code) communicate way too much with each other. Do they need to? According to the pre-refactor code, yes. Move the authentication code to its own place, and now you can’t see those cute graphs.

当两个目标非常不同的代码块(例如，身份验证代码和数据可视化代码)彼此之间的通信方式过多时，也会发生相同的情况。他们需要吗？根据重构前代码，可以。将身份验证代码移到自己的位置，现在您看不到那些可爱的图形。

如果它摔坏了，那就不够坚固 (If it broke, it is not SOLID enough)

Let’s say you refactored the code to a seamless, perfect module. Except that… you have had to compromise a few situations of code repetition among different modules, to make it work. And also, right after you commit the module, you notice that it’s actually 2 different modules! Or maybe, all of a sudden you have to extend some classes and change their behavior on this module because otherwise, it wouldn’t work.

假设您将代码重构为一个无缝，完美的模块。除了……您不得不折衷一些不同模块之间的代码重复情形，以使其起作用。而且，在提交模块后，您会发现它实际上是2个不同的模块！也许突然之间，您必须扩展一些类并更改其在此模块上的行为，因为否则，它将无法正常工作。

Well, if you have all that stuff, count the days before it breaks on its own. This seems very cheap, but SOLID code tends to break less (and be easier to extend).

好吧，如果您拥有所有这些东西，请计算一下它自己崩溃之前的天数。这看起来很便宜，但是SOLID代码的中断次数更少(并且更易于扩展)。

如果没有破裂，您是否涵盖了所有情况？ (If it didn’t break, did you cover all the cases?)

Imagine it the other way around. You do a refactor worth 2 weeks of your time. And nothing broke? What’s wrong with that then? If nothing breaks, it should be a reason to be happy.

试想一下。您进行的重构耗时2周。 什么都没打破？那怎么了如果什么都没有发生，那应该是开心的理由。

Check your tests again, because either your code was already pristine, or somebody’s about to work late next week (and it’s not me).

再次检查测试，因为您的代码已经很原始，或者下周下半年有人要工作(不是我)。

如果没有破裂，您是否真的在使用它？ (If it didn’t break, are you really using that?)

Believe it or not, we, developers, like to keep code around. Yes, even in the age of version control, we believe that having a plethora of old code around is worth the bytes it weights and the reading time it needs. If you moved something and your code didn’t change, either I really want to see that perfection or that code is simply not used. It’s not bad to discover that, it’s maybe disappointing that you spent the last 4 hours refactoring that class and it’s worth nothing, and you’ll probably want to keep it in case somebody did that on purpose (they never do).

信不信由你，我们开发人员喜欢保留代码。是的，即使在版本控制时代，我们也认为拥有大量旧代码值得它加权的字节和所需的读取时间。如果您移动了一些东西而您的代码没有改变，那么我真的很想看到这种完美，或者根本就不用该代码。发现这一点也不错，您可能在过去的4个小时中重构了该课程，这很令人失望，它毫无价值，而且您可能想要保留它，以防有人故意这样做(他们永远不会这样做)。