🧠 Complexity Brain Dump

Unstructured thoughts about 📏 Measuring Software Complexity. The idea is to come back to this every once in a while and either structure it better or simply delete it.

• This means coupling between different areas of the system

• Measurement of how much of the system you need to be aware of to understand what is going on

  • Measurement of how much complexity a single engineer needs to know to do their job (take code ownership of team + coupling (both dependencies and dependents)).

• Measurement of the complexity of a single concept within a Software System and in which way it negatively impacts the overall complexity of a system (e.g., the complexity of Employee spreading all over Pleo).

  • E.g., assign a number of complexity or difficulty to understand a concept + calculate coupling ⇒ complexity introduced as a result of the concept

• Suggestions for code refactoring based on coupling and complexity.

  • E.g., a class is big and difficult to understand. Suggestions for ‘how to slice the cake’.
  • For example, move a set of functions out of a class to create a dedicated class for a set of dependencies (splitting up classes handling replicated data and the source of truth, even though both refer to the same Entity)

• There are both opinionated and un-opinionated metrics:

  • Un-opinionated (don’t require anything from the developer, only rely on data that is the result of normal day-to-day work):
    • Code hotspots (requires looking at git history)
    • Dependencies (requires static code analysis)
  • Opinionated (requires a certain structure or effort from developers to get the data):
    • Semantic Commit Messages to find buggy hotspots in the code by checking for fix: in commit messages

• Suggestions for refactoring:

  • Analysing similar code patterns over the codebase. Is there a recurring piece of code that could be generalised and extracted?
  • Can anything be learned from underused dependencies?