Thoughts on Incremental Refactoring

[eazyhozy]

Hi everyone,

This codebase has been used in production and has evolved primarily to meet real-world needs. As it is now an open-source project, some parts would benefit from refactoring to improve structure and readability for contributors.

The goal of this discussion is to gather feedback on whether refactoring makes sense at this stage.

To help frame the discussion, here are a few questions to consider:

• Does refactoring feel necessary at this point in the project?
• If so, what kinds of problems should we prioritize addressing?
• Are there concerns or risks we should be aware of before going further?

Based on the feedback here, we can follow up with more concrete proposals and next steps.

Thanks for your time and for sharing your thoughts! 😎

[em3s]

Thanks for starting this discussion.

I agree that refactoring makes sense at this stage. Making Actionbase open source aligns well with the same long-term goal as refactoring: sustainability. As the project evolves, the focus naturally shifts from meeting immediate real-world needs to making the codebase easier to maintain and extend by contributors.

At this stage, it would be ideal for refactoring efforts to focus on improving structure and efficiency while keeping existing behavior and specifications unchanged, rather than introducing new features or API changes.

To support this safely, strengthening our testing foundation seems important. Where feasible, moving existing internal tests into the open-source repository—after appropriate anonymization or adjustments—could help us validate refactoring changes with more confidence.

With a solid test base, we can approach refactoring incrementally while continuously ensuring behavior remains consistent.

cc. @zipdoki - would be great to hear your thoughts, especially given your experience improving tests.

[zipdoki]

The internal test suites and documentation currently contain internal references and outdated versions. I am evaluating the best approach for public release and will share an update once they are ready.

@em3s

[em3s]

It’s true that we’ve accumulated many test versions over time. Instead of migrating everything at once, I suggest establishing a simplified baseline:

• Decouple: Create a lightweight setup free from legacy dependencies.
• POC: Migrate a single, anonymized test case as a template.
• Migrate: Gradually move and refactor remaining tests onto this foundation.

Starting light will make the refactoring process much smoother. Thoughts?

@zipdoki