Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code refactoring needed #161

Open
BryanGuillaume opened this issue Mar 23, 2020 · 1 comment
Open

Code refactoring needed #161

BryanGuillaume opened this issue Mar 23, 2020 · 1 comment
Assignees

Comments

@BryanGuillaume
Copy link
Collaborator

Adding additional features to the toolbox seems to become more and more difficult because there is often a need to change the code in many different places. There are mainly two reasons for the latter:

  1. Some pieces of code are repeated a bit everywhere within and also across functions. (e.g., the 2 functions swe_cp and swe_cp_WB contains a lot of code in common that is also repeated several times within functions)
  2. Some functions are tightly coupled with other functions (e.g., the results of clicking on some buttons in the result display involve several functions in the code and modifying one behaviour obliges us to potentially change all of these functions; recently, I found and fixed some bugs for some buttons that, I believe, were likely introduced because some of these functions were not changed in parallel with others)

Also, each time we were adding new features, a lot of functions had increased in size, making harder and harder to maintain them.

Therefore, it seems important to try to refactor the code, at least some parts of it. I would like to do that by splitting the code into more (smaller) functions with fewer responsibilities. To be able to do that confidently, it seems important to first refactor the tests to cover more complex scenarios than those currently implemented. I would also like to make the tests quicker to run, which makes sense if we want to add more tests. I believe that this can be easily achieved by using "smaller brains" composed of fewer voxels for the tests.

The main issue with this refactoring is that this will be quite time-consuming. Nevertheless, this should also help to make any future changes easier to implement. A trade-off would be to focus on refactoring as the implementation of new features progresses to make the code cleaner and cleaner with time.

@nicholst, can I have your opinion about this?

@nicholst
Copy link
Collaborator

Concerns

  • Structure, modularisation of the refactoring work... is it 'all or nothing', or can you do it wave.
  • Testing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants