I have about six years of experience and recently joined a company where I inherited a shipping application that integrates with an SSO service and several logistics systems. The project was outsourced, and it appears to have very little documentation, inconsistent code quality, and no automated test coverage. It uses Supabase with more than 100 Edge Functions, webhooks, database functions, and PGMQ-related logic. A coworker will also be helping with refactoring and new features, but we have different standards when it comes to code quality. For now, we have a couple of weeks to investigate the system and prepare a handover plan before making changes. How would you approach understanding a project like this, planning the refactoring, and introducing tests without accidentally breaking existing behavior?
2 Answers
Your instinct about end-to-end testing is good, but start by documenting how the system behaves before changing anything. Create characterization tests that capture the current behavior, even when that behavior is awkward or seems incorrect. These tests give you a safety net during refactoring. With more than 100 functions and many webhooks, the biggest initial risk is probably the unknown dependency graph. Map which functions trigger which webhooks, which webhooks invoke other functions, and how data moves through the system. That can reveal dead code, duplicate processing, and unexpected side effects before you touch the implementation.
Make sure all new work follows a clear standard, but avoid trying to rewrite the entire system at once. Refactor in small, focused pieces whenever you need to modify an area. Management usually will not approve spending years on refactoring alone, so connect cleanup work to features and bug fixes. Also keep communicating the size and risks of the technical debt so expectations stay realistic.
I have already written a document covering the current application, database, and some security concerns. I have about two more weeks to investigate before we create the plan. My first thought was to add an end-to-end test for the main user flow so we can detect regressions when we start making changes.