cereja-project / cereja

Cereja is a bundle of useful functions we don't want to rewrite and .. just pure fun!
MIT License
28 stars 12 forks source link

🚀 General Project Refactoring #216

Open jlsneto opened 1 month ago

jlsneto commented 1 month ago

This issue proposes a general refactoring of the project code to improve maintainability, performance, and organization. The refactoring will include, but is not limited to:

•   Dead code removal: Identify and remove unused code.
•   Modularization: Separate code into coherent modules to facilitate understanding and reuse.
•   Adopting design patterns: Apply design patterns (e.g., Singleton, Factory, Strategy) where necessary to improve structure and code clarity.
•   Improving readability and consistency: Review variable, function, and class names to ensure clear and consistent naming throughout the project.
•   Performance optimization: Identify areas where performance can be improved.

Goal

The goal of this refactoring is to make the code cleaner, more modular, and easier to maintain in the long term. This will facilitate adding new features and fixing bugs in the future, as well as helping new contributors to understand the project more easily.

Tasks

•   Analyze the current codebase to find dead code.
•   Modularize parts of the code that are too tightly coupled.
•   Apply design patterns where appropriate.
•   Improve code documentation where necessary.
•   Test all changes to ensure no regressions occur.

How to Contribute

•   If you’re interested in helping with this task, feel free to comment below and discuss specific areas you’d like to refactor.
•   If you have suggestions for additional improvements, please share them!

Notes

•   Before starting, please sync your branch with the latest version of main to avoid conflicts.
•   Ensure the code continues to follow the project’s style guidelines.
•   Make sure all changes are covered by tests.
mukulbindal commented 1 month ago

Hi @jlsneto Can I please work on this issue, I would like to improve the test cases. I would like to separate each test case in its own file, like mathtools.py has missing test cases and its in general tests.py which is not much readable. Apart from that I would like to add the missing test cases to increase the code coverage close to 100%

jlsneto commented 1 month ago

@mukulbindal Thanks for offering to improve the test cases 🤩! Your idea of ​​separating test cases into individual files seems like a solid approach, especially for improving readability. Coverage and missing tests, as you mentioned, increasing coverage is also a great idea.

For packages, we can follow a structure that aligns with how the code is organized in the project. Here's what I suggest:

  1. Package-level tests: Each package can have its own directory for tests. For example, if you have a utils package, you can create a tests/utils/ directory. Inside that directory, you would create individual test files for each module.

  2. Test structure: The test files should mirror the package structure.

Feel free to pursue these ideas and let me know if you run into any issues or need more guidance. I look forward to your input!