Thiago Duvanel
446 words
2 minutes
Refactoring patch-hub
2024-11-30

As part of my contributions to patch-hub, I’ve dedicated time to refactoring key parts of the codebase to make it more maintainable and welcoming for new contributors. These improvements aim to simplify the development process and enhance the overall structure of the project, paving the way for future growth. Basically, all the patch-hub modules were not separated in a good way, since each module didn’t have a one resposability for example, but multiple ones. The main.rs was a mess, and it was very difficult to understand where a feature was implemented.

Method extraction#

The first step in the refactoring process was to extract methods from the main.rs file to their respective modules. This separation of concerns made the codebase more organized and easier to navigate. For example, the LatestPatchsets method was moved out from key events module, while the rest of the condiiton screen match methods were relocated to the main module. This restructuring not only improved the readability of the code but also made it simpler to identify and modify specific functionalities.

Extraction from main, UI and app#

In patch-hub, there are 3 main modules: main, UI and app. The main module is responsible for the main loop, the UI module is responsible for the user interface, and the app module is responsible for the application logic. In the app module, since there were some organization about the features and the files used, it wasn’t very complicated to organize it, just separating each functionality used by each screen in a separate file and in a separate module.

In the main module, the things were a little bit more complicated, since the main was just a big massive piece of code, it was very complicated to decide where to put the files and new modules created from main in a proper way. After discussing with the other developers, we’ve made the conclusion to create some new folders and files to store them, making the main.rs file more clean and organized.

Now, in the UI area, since we have a lot of different UI methods, we’ve decided to separate them in a different way, creating a new module for each screen, and a new file for each method used in the screen. This way, it was easier to understand where a feature was implemented, and it was easier to modify it. The UI refactoring was the biggest and most complicated one.

Conclusion#

These refactoring efforts not only make patch-hub a more robust tool but also encourage new contributors to join the project by providing a cleaner and more approachable codebase. I’m excited to see how these changes will support future developments, and I’ll share updates on any further improvements in my upcoming posts. Stay tuned!

Refactoring patch-hub
https://th-duvanel.github.io/posts/refactoring/
Author
Thiago Duvanel Fereira
Published at
2024-11-30