Or let me put it this way: Don’t abuse colors. A good architect would never be proud of a complex diagram.ĭon’t Use Colors. Always use arrows, and always annotate them-this will help me understand you much faster. Is it a flow of data? Is it a compile-time dependency? There are many possible meanings. There is nothing more annoying on a diagram than a line connecting two rectangles without any text on it and without any direction. I would recommend UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) by Martin Fowler.ĭirect and Annotate Lines. Just learn the basics that will be enough to express almost any idea you have. It’s a huge format/standard/language, but you don’t need to know all of it. Well, use whatever notation you feel comfortable with, but many years ago people agreed that instead of using different notations, it would be easier to learn one for all that’s UML. I’ve seen diagrams with 25 or more rectangles … that’s unacceptable. I just made up the number five, but you get the idea-make sure all diagram participants are easy to count. I want to see them all at one glance and immediately understand who is who. You don’t want me to spend more than a few seconds trying to understand who is participating in the show you’re presenting. Just group some of them together and give it a name. Try to explain yourself in less than five.
If you have more, there is something wrong. Read on and remember that the main goal of all this is to reduce complexity. I can’t say I’m one of them yet, but I have a few recommendations for your diagrams. That’s where a true architectural mind shines. Instead, he would be proud of a simple and easy-to-understand drawing with a few rectangles that perfectly explain an entire multi-tier application. Thus, a good architect would never be proud of a complex diagram. The main virtue of an architect is the ability to reduce complexity. If I don’t understand you, it’s your fault. When the problem is properly decomposed (broken down into smaller, isolated and properly decoupled pieces), the complexity decreases, and it becomes easier for everybody to understand and resolve. Just as a good project manager has to decompose a complex task into smaller ones. Wrong! A good architect knows his main role is to decompose a complex problem into less complex components and let programmers solve them one by one. He can understand this multi-tier architecture, and I can’t.
Indeed, someone actually noticed how difficult his job is and appreciated his efforts. Usually, after that, the architect smiles with an obvious feeling of satisfaction. Oh yeah, we're solving complex problems here!
You know, your diagram looks so complex. They think that the more complex the problem they’re working with, the better an engineer they are. So why do we have them?Īrchitects are proud of complexity, that’s why. Why is this happening? Why are their diagrams complex and difficult to read? I’m sure you know what I’m talking about you probably have your own examples of such diagrams from projects and architects you’ve worked with. What’s worse is that the complexity goes up in line with their salaries-it’s disgusting. But the diagrams are usually very cryptic and hard to digest. They use diagrams, which are the most popular instruments of an architect, to explain to us, programmers, what he or she has in mind.
SIMPLE DIAGRAMS IN ARCHITECTURE SOFTWARE
They don’t understand that the job of a software architect is to make complex things simple, not the other way around. This has to be the most basic, fundamental principle of a good software architect (well, of any engineer), but most of the architects I’ve met so far, in many companies, don’t seem to believe in it. Let’s begin with this: If I don’t understand you, it’s your fault.
0 kommentar(er)
