IxDF Developer Docs

Appearance

Code Owners ​

IxDF Developers have different areas of expertise in different modules. Due to this reason, we have introduced the concept of "Code Owners": Every important module SHOULD have 2+ owners.

Modules ​

Types ​

There are two main types of modules:

  1. Product Modules - modules more or less visible by our end-users that add value to the product (in terms of DDD: "Core Domain" + "Supporting Subdomain").
  2. Supplying Modules - modules hidden from end-user application parts (like logging, caching, geo, currency converters, etc.) (in terms of DDD: "Generic Subdomain")

*Order of modules is important.

Documentation quality ​

📄 Documentation quality is rated at one of three levels:

  • Needs Heavy Updating
  • Mediocre
  • IxDF Gold Standard

The long-term goal is to bring all module documentation to IxDF Gold Standard.

Product Modules ​

Dev note: when update this list, please also update CODEOWNERS file.

Supplying Modules ​

How to use it ​

This concept helps:

  1. for non-developers: to assign the right developers to related bug reports and feature requests.
  2. for developers: to feel accountable for the code.
  3. for developers: to assign other developers to PRs as reviewers.

But the main point is OWNERSHIP. We expect that module owners will take care of all issues for modules assigned to them (where they are the first person on the list), know module problems, build short-term and long-term plans for them and be in charge of all decisions (and a lack of decisions also) we make for those modules.

Code Ownership types ​

There are various schemes for Code Ownership. Martin Fowler put them into three broad categories:

  1. Strong code ownership breaks a code base up into modules (classes, functions, files) and assigns each module to one developer. Developers are only allowed to make changes to modules they own. If they need a change made to someone else’s module, they need to talk to the module owner and get them to make the change. You can accelerate this process by writing a patch for the other module and sending that to the module owner.
  2. Weak code ownership is similar in that modules are assigned to owners but different in that developers are allowed to change modules owned by other people. Module owners are expected to take responsibility for the modules they own and keep an eye on changes made by other people. If you want to make a substantial change to someone else’s module, it’s polite to talk it over with the module owner first.
  3. Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. You can consider this as no code ownership, but its advocates prefer the emphasis on the notion of ownership by a team as opposed to an individual. (The term collective code ownership comes from Extreme Programming, although in the second edition, the practice is called Shared Code.)

At this moment, we follow Weak code ownership scheme, but we like Collective code ownership, and we’re doing our best to migrate to this scheme.