Skip to main content
HashnodeMaximiliano Contieri - Software DesignMaximiliano Contieri - Software Design

Command Palette

Search for a command to run...

Code Smell 47 - Diagrams

Updated
•2 min read
Code Smell 47 - Diagrams
M
Maxi Contieri

I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.

Part of seriesCode Smells

Diagrams are not code. They cannot be a code smell. They are just Diagram Smells.

TL;DR: Don't use diagrams. They are obsolete and dead.

Problems

  • Maintainability

  • Trash code

  • Code Duplication

  • Diagrams focus only on structure (accidental) and not behavior (essential).

Solutions

  1. Use diagrams only to communicate ideas with other humans.

  2. Program on your favorite IDE.

  3. Thrash all diagrams. Even the ones generated from the source code.

  4. Trust your tests. They are alive and well maintained.

  5. Use Domain Driven Design technique.

Sample Code

Wrong

class-example-library-domain.png

Right

https://gist.github.com/mcsee/36f0af6785ea36a05c3ec394fa71e4e8

Detection

We can remove all code annotations and forbid them by policy.

Examples

Conclusion

Designing is a contact sport. We need to prototype and learn from our running models.

Papers and JPGs don't run. They live in the utopic world where everything works smoothly.

CASE was a very hot trend back in the 90s. No good system was developed with these tools.

Relations

https://maximilianocontieri.com/code-smell-01-anemic-models

https://maximilianocontieri.com/code-smell-25-pattern-abusers

More info

https://maximilianocontieri.com/lazyness-ii-code-wizards

https://en.wikipedia.org/wiki/Computer-aided_software_engineering

https://en.wikipedia.org/wiki/Domain-driven_design

Credits

Photo by Nick Seagrave on Unsplash

The Diagram is Not the Model. The model is not the diagram. It is an abstraction, a set of concepts and relationships between them.

Eric Evans

https://mcsee.hashnode.dev/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://mcsee.hashnode.dev/how-to-find-the-stinky-parts-of-your-code
#programming#code-smell#clean-code#2articles1week#software-design
695 views

Comments (1)

Join the discussion
C
Chris Bongers5y ago

I tend to disagree, we still use diagrams and functional designs to help understand the semi/non-technical client what we are building.

It's a decent way to validate if what we are going to build is what they envisioned.

We rather spend the hour making the diagram and functional designs than building something only to realize it's not what they wanted.

2
M
Maxi Contieri5y ago

Sure !

But you use diagrams to talk to other humans. That's a very valid scenario.

I prefer to validate what user wants using TDD.

The main problem with diagrams is that you discuss DATA with users. And data is accidental. You need to discuss behavior with them. And, IMHO, functional tests and acceptance tests are better for it.

We can validate rapid prototyping and validations with diagrams or Acceptance tests. I prefer the latter.

2

Code Smells

Part 1 of 50

In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most are just clues. They are no hard rules.

More from this blog

M

Maximiliano Contieri - Software Design

476 posts

Learn something new every day. 💻 CS software engineer 👷working 👨🏽‍🏫teaching ✍🏾writing 🎨Software design 🏢SOLID 🌉TDD 👴Legacy

Write me at info(at)maximilianocontieri.com