80
It‘s a question of risk management:
refactoring a system, always creates the risk of breaking something that worked before.
the larger the system, the higher its complexity, and the higher the risk of breaking something.
with spaghetti-code (or any other poorly structured code) the real structure of the code remains fuzzy, and the dependencies might be ...
54
One reason is it's really difficult to measure the loss of productivity the messy code is causing, and difficult to estimate the work it will take to clean it properly and fix any regressions.
The other reason is many developers incorrectly call any rewriting refactoring. True refactoring is very methodical, almost mechanical. You make very small changes ...
24
It depends on your definition of "correct practice".
I'm currently working on said old spaghetti code, much of it is old enough to drink. It's a critical safety system.
Changes to this code have to be audited and signed-off by an independent third party. The owners of the company consider it to be "correct practice" for the company not ...
6
How do you define 'correct'?
I have seen more disasters when people tried to fix something that was not broke by fixing spaghetti code.
There are times when you will be forced to make changes.
Some folks try to totally rewrite it 'correctly'. Those attempts usually take longer and have more problems than they estimated; and sometimes they fail completely.
I ...
5
Strangely, code reuse is still a useful idea even when the code isn’t being reused.
Most code isn’t reused. Yet code reuse is still a popular idea. Why? Because when you design code to be reused you design code that is self contained. Code that makes sense on its own. Code that makes explicit anything it depends on.
Reusable code is readable code precisely ...
4
Some DDD practitioners suggest that it is ok to inject technology layers dynamically into your domain model. Modeled that way, your domain code will not be directly dependent on technology components and only talk through abstract interfaces.
But I would suggest that you keep only the domain related code in the domain model layer and organize all technology ...
3
Generally speaking (and this is true outside of DDD), you want to arrange dependencies so that code depends on things that are more stable then itself. Here stable means something that changes comparatively less often as the software evolves. (Initially, you'll have to go with an educated guess based on your understanding of the domain, but over time, as you ...
3
You need a reason to be changing any code. That reason may be as simple as dead code (unreachable), making it easier to read (loops to LINQ for instance) or as complex as refactoring multiple modules for multiple interrelated reasons.
When refactoring important and large blocks of code, the first thing to determine isn’t how desirable or even necessary the ...
2
The 1 logic is that due to inheritance. But, except that how does Object Oriented Systems helps in reusability?
In a very abstract sense - and in consequence not only held true for OOP - every programming paradigm which helps to modularize your codebase helps reusability, independent from the actual content, be it functions, procedures, classes etc.
And ...
2
The benefit of events is that you (or more precisely, consumers of your component) can subscribe to them. The one implementing the event handler is typically not the same person as the one that created the object that publishes the event.
Events make an object more versatile. They allow the object to be used in a context unforeseen by its creator without the ...
1
There are two levels of abstraction in your question:
1) What is happening programmatically in my code
2) What is happening under a system's view in my system modeled by my code
Setting a property (programmatically) is simply a statement of your code which gets executed. So from a POV of your system everytime a statement is executed, something is happening ...
1
By factoring into common base classes with differences handed in subclasses, the base class is the home for reused code. OOP directly supports this factoring.
Further, a single operation (e.g. on a base class object) can be split into multiple methods, where one of those methods is meant to be overridden by the specialized subclass, meaning that the others ...
1
I once had the joy of watching someone “refactoring” some legacy code that I had written, about two years earlier. My code was complicated, because it covered about two dozen corner cases that had been found through intensive testing. Each corner case handled was heavily documented.
The new code was a beauty. It was a quarter of the size, and very easy to ...
Only top voted, non community-wiki answers of a minimum length are eligible
