|
|
|
|
|
|
by graphviz
861 days ago
|
|
|
This is nice work on graph visualization, but we learned years ago that readable network visualization does not necessarily mean good software architecture. For example, a good drawing of a tree may be easy to read and even beautiful, but may reflect an underlying design with no re-use or modularity. A graph of relationships between functions in an abstract machine may look very complicated, but that doesn't mean the design is poor. Graphs are wonderful abstractions for the structures that arise in many kinds of engineering, but you need to focus on understanding those abstractions, not just pictures rendered by heuristics. Visualization can be wonderful, but has its limitations, especially when used out of the box. |
|
|
For some projects, you need to think really hard to design it correctly. The most extreme experience that I've had of this was when I was working in the blockchain sector.
Initially, when I joined, the project was a tangled mess. Every module was connected to many other modules without clear separation of concerns and with tight coupling.
For the refactoring, we extracted the core crypographic logic and separated it from the network/P2P logic which we re-wrote from scratch. I designed it so that the P2P module would be fully data-agnostic; meaning that it would have no concept of what kind of data it would have to propagate through the network. It was a significant challenge to come up with such design while also supporting features like peer banning, peer selection, peer shuffling, preventing messages from rebounding back to the sender, preventing spam and duplicates... During the design phase, I was tempted many times to add some kind of business domain awareness to the P2P module but managed to resist until the project's completion.
The result was that the P2P module ended up with a very simple interface and was very versatile. Because it wasn't tied to any specific business domain, it could be used for a broad range of different blockchain consensus mechanisms and didn't require any code updates when business requirements changed. This was useful to us at the time since we had not settled on most details of our consensus mechanism. Also, it could be used for a wide range of other P2P use cases beyond blockchains; later, I was able to use that exact same module (without any changes) to build a DEX (decentralized exchange) with only about 4000 lines of additional custom code.
More interestingly, there was another blockchain project which was similar to the one I was working on and they also decided to have a P2P module but their module had awareness of business domain concepts such as 'transactions' and 'blocks' and their code was much messier, much longer and not reusable at all. They had to update it almost every time their business domain requirements changed and it wasn't as reliable.
It was the exact same problem, but the second project gave in to the temptation of sharing business domain responsibilities across multiple modules (low cohesion) and this led to tight coupling.