wiki:org/meetings/2019BrusselsNetworkTeam/Notes/Modularization

# MODULARIZATION

better modularization in the future modularization?

you can understand pieces of it in insolation the amount of parts you need to look at to understand what a part is doing it is small you can replace it one at a time, you can test it one at a time?

what stands in the way of understanding pieces of our code?

. many of our data types are use in through the codebase . modules that need to know about dozen or hundreds of other modules

. config.c module: initializing and configuring a number of things . control.c module: provide an interface to a number of modules and also tell controllers about anumber of modules . main.c module: it calls a lot of things Those are a bad sign where modularization breaks down.

Comment layer: everything in source comment.

  • it is separate in different layers.

Source OR: everything else.

Increasing modularity: reducing data visbility and exposure (a second one) reducing our calls

What tools do you use to do this?

. suggestions:

. sub-system idea used in tor . putting stuff in different directors . message passing system . systematic use of our handle stuff . tooling to measure our modularity violation

what do we want our code style to be?

Other things that make harder to understand code in Tor:

  • big functions are hard to understand (more than 5 pages long)
  • modules that go over several thousands lines long
  • complex branching structure
  • state transitions: we do not have a good way to represent state and state transitions (cut the number of posssible states of what a things can be in) (around the hashrings are complicated to understand)

I would like a new file script that does all the right things to create a new module

End of the project: have a rule that says that every new feature has to be in a module that is off by default.

A styleguide: how we want the code to be module.

# GOALS FOR REFACTORING CODE

  • Network scalability
  • Network performance
  • User-percieved performance
  • Hardware-optimal performance
  • Space/memory efficiency
  • Ease of core component replacement
  • Ease of development
  • Reduced code complexity
  • Better unit testability
  • Technical debt reduction
  • Security/stability
Last modified 3 months ago Last modified on Jan 30, 2019, 4:17:51 PM