Surviving Your First Legacy Codebase

Welcome to the first edition of Beyond the Bootcamp, your weekly guide to surviving excelling as a new developer in the workplace! Today, we’re diving into something every junior (if you get further, you're lucky) developer encounters sooner or later: legacy code.

You'll also find some recurring sections on FAQs, tips, and events at the end ?

What is Legacy Code?

An existing codebase that:

?? You didn’t write

?? Is often poorly documented

?? Might lack tests

?? Could be using outdated technologies (99% of the time ?? )

Sounds scary? Don’t worry! Here’s how you can understand, work with, and improve legacy code without breaking everything.

Let's be real: Legacy code is a challenge for everyone. Even your managers likely dread working with it (unless they're the original authors!).

How to Work with Legacy Code

STEP 1: Understand the Business Logic

Your job isn’t just to understand the code, but also the why behind it.

This really helps you to understand the logic, and translate any tricky bits of code if you already know the flow.

Action Steps:

? Ask your team about the service’s purpose

? Find service or architecture diagrams to give you an overview of key data models and how they interact

? Look for API endpoints or database queries - this can help you see the inputs/outputs of the service, and what data it handles

Questions to Ask Your Team:

• "Where are the entry points to the service?"
• "Are there any known pain points or bugs?"
• "Is there any documentation, including diagrams?"

STEP 2: Find or Write Tests

Tests show the expected functionality of a system, sometimes in a human-readable format

??Don't change code without tests unless you're advised to (and even then, still challenge it)

If there are existing tests (which there hopefully should be):

??Run them to see what’s covered

??Read test files to understand expected behaviour

?? If you can’t run it locally, view test runs (e.g. in Jenkins)

If there are no tests:

??Write small tests before changing anything, or

??Perform manual tests if possible

Ask your team to run you through any tests you're not comfortable with.

STEP 3: Read Before You Write

Resist the urge to dive in. Understand the code before making changes.

Start by reading the code before modifying it. Look for:

• Entry points (e.g., main.py, index.js, app.rb, Application.java or Controllers)
• Configuration files (.env, config.json, .yaml)
• Dependencies (package.json, requirements.txt, Gemfile, pom.xml)

Use IDE tools to explore function definitions (e.g. JetBrain’s apps have an endpoints area). Finally, if you can, run the app locally and follow logs to see what happens behind the scenes.

It can be difficult to run legacy code locally* - if this is the case, see if you can run in a different environment**!

Helpful Tools

• git blame – see who has edited code & when. You can then speak to them, or perhaps find the tickets and related PRs for their changes to gain some more context.

*locally = on your PC/laptop, just pulling the code and running it.

**environment = a different place to run your code, like on a cloud-hosted machine.

Step 4: Refactor Safely

Once you understand the code, you might be tempted to rewrite everything. Don’t!

Follow the Boy Scout Rule: “always leave the code a little cleaner than you found it.” - Robert C. Martin

? Small, incremental changes are safer (and easier for you) than big rewrites

? Use feature flags to test changes in production

? Write clear Git commit messages (e.g., "Refactored order total calculation for accuracy")

Step 5: Document What You Learn

You've spent all this time understanding and working on something, help the next person (or your future self) out!

? Update or create README files

? Update or create an internal 'wiki' page (e.g. Confluence, Notion)

? Write short comments explaining why something is done a certain way (this depends on your teams stance on comments)

? Share findings with your team - be careful though, it's very easy to become the codebase go-to

TL;DR

TL;DR = too long; didn't read

Common Pitfalls to Avoid

? Deleting "unused" code too quickly – some pesky bits have very particular use cases that may come back to bite you in the form of a prod failure tomorrow

? Overcomplicating refactors – keep changes simple

? Not asking for help – existing developers have the scars. Use their experience!

Key Takeaways

? Read first, then write

? Learn the business logic

? Use tests to avoid breaking things

? Refactor gradually

? Document as you go

Moving on from this week's topic, here's some extra tidbits.

Ask a Senior Developer

? "How do you stay updated with the rapidly evolving tech landscape?"

Colleagues and peers are your first port-of-call. Engage in 'have you seen this?' slack posts, or get chatting pre-meetings! I've learnt so much from my colleagues from the odd article they saw in passing.

Tech News sites - although these can be a lot to filter through. The BBC has some good concentrated headlines.

Newsletters! I personally like TLDR for tech/crypto news, and The Know for general happy updates.

If you want to access these using a referral link (I get free stickers ??)

??TLDR referral

??The Know referral

Okay I didn't have a senior developer to ask directly for this one, but - it's my answer influenced by tips I've been given by seniors! I'll be using my colleagues - or anyone who volunteers for future issues.

Events for your radar

A couple of events I've had a look at for this month. I'll be at the Manchester one (work permitting)!

? AWS Cloud Women - Manchester
New Year, New Tech: Empowering Your 2025 with AWS, Goal-Setting, and GenAI Productivity - Thursday 16th January 17:30 - 20:30 

? Women in Technology: London Networking Mixer 
Thursday 23rd January 19:00 - 22:00         

?? Link to signup to AWS Manchester event

?? Link to signup to the London Networking Mixer

?? Know of an upcoming tech event? Let me know!

Personal Note from Me

I’ve met my team for a new job this week, and everyone has been so lovely. One tip from me - don’t run up the stairs in an office. Embarrassed myself in front of both of my managers, and have limited knee movement now. Stay graceful ladies ??