wiki:org/meetings/2017Amsterdam/Notes/FindingTechnicalDebtsinTor

Finding Technical Debts in Tor

  • As with any long-standing software project, technical debt will accumulate, and should be taken care of when possible. In this session, we talked about sources of Tor's technical debt, when and how to tackle it, and coding standards for the future to help not accumulate technical debt.

  • We talked about using tools to analyze the complexity within the current code base, and how to reduce interdependencies. Nick talked about a call graph tool he has been working on, and we talked about other potential candidate tools. We decided that we didn't want to use something heavyweight that requires adding annotations to the code.

  • With any software project, balancing adding new features versus refactoring existing code is always tough. We talked about how when adding new features, this is an opportunity to refactor existing code as well.
  • We also talked about the inter-module dependencies in tor code. There is a "blob" of strongly connected modules, which was worse, but has been slowly getting smaller (but needs to get even smaller!).
  • We discussed how tor modules can be separated into independant libraries, rather than maintaining a single monolithic program.

  • We also focused more on coding standards to reduce tech debt in the future. Some things we discussed are:

  1. Limiting function size to what can fit within a screen (50-60 lines)

  1. Limiting test function size similarly, and using contexting to group similar tests

  1. Limiting module size, focusing on single responsibility

  1. Reducing what is available publicly. or.h is a good candidate for refactoring, a lot of its structures can be made private within modules

  1. Tests should be added for new functionality, and when changing legacy functionality
  1. We should be more strict when accepting new code and changing legacy code in general, balancing of course the when there is a need to merge something quickly.

  1. Reducing size of commits, which should help when reviewing code
  1. Limit block nesting depth (opinions vary but we discussed 3 as a max depth)
  • We also discussed the stability of the Tor API, as currently, we don't advertise having a stable API. However, doxygen output might lead people to think otherwise. We should add a warning about this.
  • We also want to follow up with mobile applications that use tor, to see how they are consuming the tor API.
  • Another action item we identified is to improve the existing coding style guide for Tor, to make it better organized and more comprehensive.
  • Finally, we identified that better modularization will help when tor runs on resource-constrined environments, such as on mobile. By having metter modularization, clients won't need to include all of tor source files. In short, there is no need for a mobile client to compile with directory authority source code, which is currently the case.
Last modified 8 months ago Last modified on Mar 29, 2017, 8:26:22 PM