Илья Фофанов
As I understand from the 15th episode there are 2 advantages of proper components development:
- An opportunity to change and redeploy only one component (.dll) instead of whole system recompilation and redeployment.
"Indeed, you should be able to hot swap components without breaking the system down." - Developers can change components independently without interfering to each other.
Ok, I see.
But I quite don't understand that statements without dactylic explanation. At least the first.
For example, lets consider the company I work for and our new project.
1. Our team seats in one room and consists of 5 developers. We have access to all source code and our system does not provide public API for external users. Our system is under our control totally. I can build the whole solution in a 1 minute or less. So I don't see in our case even one reason to be preoccupied about deployability abilities :) What benefits could we gain from proper components separation or dependencies management?
2. Our teamlead refuses such an argument because of the fact that AutoMerge works pretty good in modern SVCS (such as TFS).
So, is it right that the public API's development differs from the closed systems development greatly? I'm sure they are, but is it right in the context of the "componets topic"?
And why am I need to be able to hot swap components? In what circustances this matters?
Uncle Bob
1. Our team seats in one room and consists of 5 developers. We have access to all source code and our system does not provide public API for external users. Our system is under our control totally. I can build the whole solution in a 1 minute or less. So I don't see in our case even one reason to be preoccupied about deployability abilities :) What benefits could we gain from proper components separation or dependencies management?
The primary benefit that small teams get from good component management is the separation of concerns. One set of components contains the high level policy of the system, unpolluted by details. Another set contains the lower level details of the system. The detailed components depend upon the high level components; but the high level components are independent. This prevents (or at least minimizes) the chance that a small change to one of the detailed components can cause a malfunction in one of the high level components, or a different lower level component.
Without this kind of separation you are likely to find yourself with a fragile system; one that breaks in mysterious and hard to find ways when small and simple changes are made. System's like this are a manager's and customer's nightmare. They ask for a simple change; but when it's delivered, something else has been broken, and nobody can tell them why. Situations like this make the managers and customers believe that the development team has lost control of the software and don't know what they are doing.
2. Our teamlead refuses such an argument because of the fact that AutoMerge works pretty good in modern SVCS (such as TFS).
Yes, most source code control systems have good merge capability nowadays. That's not really the issue. The issue is keeping things separate so that they don't interfere with each other. The issue is protecting the high level policy from the low level details.
So, is it right that the public API's development differs from the closed systems development greatly? I'm sure they are, but is it right in the context of the "componets topic"?
There are certainly differences, but the basics of software design remain the same; and the separation of concerns is one of the most basic of all software engineering rules.
And why am I need to be able to hot swap components? In what circustances this matters?
Hot swapping is nice when you have a system you can't afford to turn off. You'd use a runtime management system like IOSg to hot-swap components. You probably don't have this need; but the discipline required to make it work produces very nicely separated code.