I have about six years of experience and recently joined a company where I'm taking over a shipping application that integrates with an SSO service and several logistics systems. The project was outsourced, and the existing code appears to have little testing, documentation, or consistent code quality. The application uses Supabase with more than 100 Edge Functions, webhooks, database functions, and message-queue logic. I'll be working with another developer on refactoring and adding features, but we currently have almost no test coverage. For the next couple of weeks, we're expected to investigate the system and prepare a handover plan rather than write code. What's the best way to understand a project like this, document its risks, map its dependencies, introduce tests, and gradually refactor it without breaking existing behavior?
2 Answers
Treat the project as a controlled rescue rather than attempting a massive rewrite. Document the current architecture, database, integrations, security concerns, deployment process, and known failure points. Also communicate the technical-debt risks and estimated effort regularly so expectations are clear. New work should follow better standards immediately, while refactoring should happen in small, focused pieces alongside feature work. Management is unlikely to approve years of refactoring with no visible product progress.
An end-to-end test is useful, but first map how the system behaves today. With more than 100 functions and webhooks, the biggest danger is not knowing the call graph and the potential blast radius of a change. Identify which functions call each other, which events trigger which webhooks, what external services are involved, and which database tables are read or modified. Before refactoring, add characterization tests that record the current behavior, including awkward or undocumented behavior. They act as tripwires when a change accidentally alters something users or integrations depend on. This investigation often reveals unused functions, duplicate event handlers, and conflicting business logic.
I’ve already written a document covering the application state, database, and some security issues. I have about two more weeks to investigate before we create the handover plan. My initial thought was to add an end-to-end test for the complete application so future changes have a basic safety net.