# Benefacto

Ben has contributed to a considerable amount of dOrg projects since he joined. However, he'd been working for Opolis for a very long time; and his open source contributions, which are prior to that, are around 2 years old or more.

So I requested to go over his contributions for Opolis, but due to NDA restrictions I cannot meaningfully perform automated analysis or post its result without compromising the privacy of the source code. Therefore, below you will only find my human analysis.

## Opolis LLC API: In-depth analysis

### Human analysis results:

#### Positive highlights:

- The application contains unit tests for core functionality
- It also contains integration tests. Ben came up with the user flows and edge cases to test against and they're all tested. Test cases were pretty thorough
- Application is dockerized, so it's easier to port and integrate with CI/CD pipelines. Note that this was already a pattern with Opolis's apps; but it's still good.
- Data modelling looked correct. Rationale behind models showed understanding of how the modelling affected the business logic of the application.
- The application acts as an orchestrator of several different microservices. Concerns looked well separated, each with their own wrapper abstraction.
- External third-party services like Stripe have their own wrapper abstraction around it
- Business logic is well separated from model/data logic
- Constants are being abstracted into constant variables instead of using literals
- While the microservices architecture was already chosen and in place by Opolis, Ben understood it, adapted to it and took correct design choices for the application to work/integrate with the rest of the client's systems

#### Points of improvement:

- Prefer type annotations over type comments unless you need to support legacy Python. Annotations provide a cleaner syntax, keeping type information closer to your code. They are also the officially recommended way of writing type hints, and will be further developed and properly maintained in the future. Type comments are more verbose and might conflict with other kinds of comments in your code like linter directives
- Folder structure could be improved by grouping files by purpose or nature. That way, the code's easier to navigate through, and requires less mental load