Interview: Michael Stal on Architecture Refactoring
- Share
-
- |
Read later
My Reading List
In this interview, Michael Stal describes what architecture refactoring is about and how it relates to both code refactoring and patterns. He describes some architectural refactorings by giving real work examples from his work as Siemens, and he elaborates on some situations where you may want to avoid doing this kind of refactorings.
From the interview:
One of the most typical examples is, if you are a software architect in a project and as I said before normally you are trying to be very elaborate, you are trying to be very sophisticated only to the changes in a very systematic way, but that’s not the way it works of course in practice. So basically what happens after a time that sometimes in space and time you get situations where your architecture gets messy. For instance you get dependency cycles and these dependency cycles are one of the most obvious problems or all of the sudden you subsystem A depends on a subsystem which depends on a subsystem C which also depends of you original subsystem A, which makes the system less testable because if you have to test A, you also need to touch B, C and so on. If you want change something in A you have a dependency on B, so you have also to change something in B and all of these problems are really obvious. One of the architecture refactorings which really is applicable to this kind of situation is how to break dependency cycles. For instance, one solution could be just inverting one of the dependencies, so instead of having a dependency from A to B, try to come up with a dependency from B to A instead, in order to break this kind of dependency cycle.
Michael also describes when he went out looking for literature and other writing in this area and found virtually nothing written about it, and what he hopes to do about it.
Watch the "Michael Stal on Architecture Refactoring" interview.
Architecture isn't in the code?
by
Jeremy Wales
Have I missed something? I may well have as my XP leanings get me riled at any hint of separating architecture from code :-)
Architecture Refactor
by
Pete Haidinyak
notes about Architecturing Refactoring
by
William Martinez
Refactoring is changing of code in order to improve design without changing functionality.
To me, architecture and design are higher level coding. Code (micro-design) has to be the same solution, just more detailed, than the actual design (Tactical level) which is at the same time a more detailed description of the solution from the architecture design.
Thus, a dependency is reflected in all three levels. There is no way a dependency may be in one level and not in another one. You may not have the best view to catch it, though. Maybe you have no detail in a higher level to see that dependency (a dependency is inside one class or between classes inside a functional unit), or looking at code you cannot detect a global dependency (usually three+ way dependency).
A refactoring in any part may affect any of the other levels, so all should be maintained up-to-date. A refactoring made from strategic level will impact coding, 90% of the time. I code is actually well written, changing a communication way from WS to REST for instance, will require changing probably one class and all should work the same. If it is all tightly coupled, then changing that may require rewriting half the application.
There are several more issues about this. It is interesting, so I may post something more related to this in my blog .
William Martinez Pomares
DSM Methodology might help
by
Han van Roosmalen
Lattix support an ever increasing number of platforms, like Java (incl Spring and Hibernate), .Net, SQL Server, Oracle, Delphi Pascal, C/C++. Buildtime it checks for dependency violations, so there is a great way to measure deviations to the intended architecture.
The method proves to be very helpful to architects, and other less technical people. It opens discussions based on what you see in the matrix in stead of gut feeling.
Educational Content
Large-Scale Continuous Testing in the Cloud
John Penix May 24, 2013
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think