Development process (notes for stability)

[lontivero]

- very draft, ignore

Introduction

The team has decided to focus on achieving a more stable code base of Wasabi and for that reason most of the development effort is being invested on bug fixing and building an uniform experience across the different platforms.

It is my personal opinion that if well the goal is the right one, it is necessary to approach the task with a more delimited set of practices and processes. I will propose here what I think should be done.

Background

- this section can be skipped

Wasabi wallet was developed using a novel technology unknown for two out of three team members and with a challenging due date for the first working version, the goal was to have it done to present it during the Building Bitcoin (Lisbon, August 2018). The most important parts of the UI were coded in less that two weeks in a learn while doing approach.

After the first release version (1.0.0) the development continued driven feedback from users who requested improvements and features so, most of the development effort was invested in the development of new features under a highly frequency release cycle, that's why since October 31, 2018 (release date of the first stable version) there were 10 releases, most of them containing new features and also bug fixes, most of which were introduced in the previous release.

Hands on

A few things that I write here had already been implemented but It is important to put them here explicitly. The list of

Develoment

Code Reviews

All code has to be reviewed before being merged to the master branch. It could be good to have all the code reviewed by more than just one developer when possible.

Code complexity

Wasabi design is not complex but its code is. There is a bit high level of coupling in the components that makes it no so easy to isolate to test and there is a low cohesion intra-component because they use to work at different level of abstraction. Also, the cyclomatic complexity looks high mainly because of the null reference checking code, and exception handling.

In order to reach an agreement on what cleaning code means, this is what I understand that has to be done:
Decouple code, break dependencies, avoid passing/returning null, reduce cyclomatic complexity, refactor for achieving higher cohesion intra component.

Configuration management

We should define clearly what is supported and what is not, which dependencies we work with, which versions, etc. This is to avoid the introduction of breaking changes.

First of all we have to keep dependencies under strict control. No new dependencies should be allowed and do not upgrade components to unstable versions. If possible it could be a good idea to stick to those we know work okay and only upgrade after we are sure the new versions also work.

Define what OS/distributions/versions we support "officially". This is important for testing and support.

Q: What criteria needs to be met to say that a new release is "ready"?

Testing

Testing is unavoidable and it is critical to achieve a product with a minimum level of quality. We should implement testing in different of different types

• Unit tests
• Integration tests
• UI Tests / Mock tests (this could be manual but it doesn't scale at all and it expensive)

Unit tests

We should write unit tests for our code and cover most of the code flows. To be able to do this we need to write testeable code and be able to break dependencies. We have a debt in this point because the project has very few tests and even less unit tests in part because the code is not easy to tests.

Integration tests

Wasabi has many integration tests that are very useful. We just need to continue writing these tests when possible.

Manual test

Testing does not improve the code, reduce complexity nor improve maintainability but it is the only way to catch defects so, manual testing should be performed before merging every PR and not just at the end of the release cycle. These has to be done by the team members.

Given this kind of tests are slow, boring, very expensive and that its effectiveness decrease with the time, it would be a good idea to invest some time to research how to automate part of it.

Code freezes

We could consider to have a code freeze days before the release. This is in general a weird practice but i think it could help us temporarily.

Preview/Beta testing

We should consider to have release candidates as part of our development life cycle.
Once all the features, improvements, bug fixes have been merged to master and during the code freeze period, we could make available a release candidate or preview in order to have feedback from our user base and release a week after that.