4 ms·
A good example of why the fundamental rule of refactoring is don't change behaviour (such as taking a dependency on a http request where there wasn't one before
by taberiand 6y ago
A good example of why the fundamental rule of refactoring is don't change behaviour (such as taking a dependency on a http request where there wasn't one before)
- sqldba 6y agoThe problem is noticing that you are changing a behaviour.
- faeyanpiraat 6y agoAutomated tests to the rescue
- TeMPOraL 6y agoThe problem is noticing that something is a behavior that needs to be tested.
- alkonaut 6y agoThe author didn’t consider that a changed behavior - the inlined image already had a dependency on http to be downloaded in the first place. No, this is all on the original author.
- deleted 6y ago[deleted]
- taberiand 6y agoI argue that the inline image had no such dependency, as it was an internal component of the control and could just as easily be used in a non-http context. By loading the image through a http request, the image component is effectively being injected with the http service in order to operate. The correct refactoring is one the author fuelled with coffee, which is naturally the real lesson here.
- jacquesm 6y agoPrecisely that. This isn't refactoring per-se it is focusing on the cosmetics of the code at the expense of functionality. There are many other reasons why an inlined image may have been appropriate and the author overruled all possible concerns by going for replacing a large block of 'ugly red' by a smaller block 'pretty green', which is a very bad reason to make a change in functionality, especially without understanding what is going on.