0

It's difficult to understand the meaning of the question from the topic's name.

Here is what I mean.

I'm watching Uncle Bob's Clean Code Episodes. In many episodes where he is talking about SOLID principles he mentions the problem of rebuild and redeployment caused by code changing. He says that bad architecture causes frequent rebuilds and redeployments.

But I have a couple of questions:

  1. Why frequent rebuilds and redeployments is bad?

  2. Can you enumerate causes of rebuilds and redeployments of dll's?

  3. Is there any difference between different languages according to the second question?

  4. What causes rebuild and redeployment of dll's in C#?

The second question (and the most common) is based on dll's coupling. What should I change in one of two coupled dll's so then I have to rebuild and redeploy the other?

  • I don't know about #1 presuming you've got a modern continuous integration system running and decent automated testing then that isn't a bad thing at all. – Wyatt Barnett Mar 18 '13 at 18:25
  • This is too many different questions for one post. Please focus your question. – Kazark Mar 18 '13 at 18:30
  • The second question is based on dll's coupling. What should I change in one of two coupled dll's so then I have to rebuild and redeploy the other? – EngineerSpock Mar 18 '13 at 18:35
2
  1. Because it's extra work, and a source of potential errors. If you don't have to deploy, there is no possibility of error in the deployment process. Deployment can be expensive if you have to take down one or more servers to do it.

  2. Anything that changes a DLL will cause a rebuild and redeploy. Specifically, if you make a change to the DLL's code, you will need to rebuild and redeploy it (assuming the change is a significant and desirable one).

  3. Some languages like Erlang have "hot deploy" capabilities, which means that you don't have to take down the server or device to deploy changes. This is useful for things like phone switches and traffic lights which must be running 24x7.

  4. See 2.

Bad architecture, from Uncle Bob's point of view, means that the code is too tightly coupled. Code that is too tightly coupled causes increased rebuilds and deployments, because your code has too many dependencies on other code in other DLL's. Consequently, making changes to one DLL often cascades into changes required in other DLL's.

  • In one of the episodes Uncle Bob said that changing switch statement in one dll affects the depenedent dll and causes rebuild and redeployment. But why? Or maybe I just misunderstood his thoughts? – EngineerSpock Mar 18 '13 at 18:56
  • You'd have to ask Bob that. But generally too many dependencies are the cause. If there's no dependency on the other DLL, or your change isn't a binary breaking one, there's no redeployment of the other DLL needed. – Robert Harvey Mar 18 '13 at 19:13
  • @EngineerSpock usually a switch statement will perform different logic based on an input parameter. If the cases are built around implementation classes, and a new class is added but the switch statement isn't, what should be the expected behavior? It's a violation of OCP and also means it's tightly coupled to the implementing classes. – Agent_9191 Mar 19 '13 at 2:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.