Script Valley
Reading Other People's Code
Contributing to an Existing Codebase/Assessment

Practice & Assessment

Test your understanding of Contributing to an Existing Codebase

Multiple Choice Questions

6
1

You need to change a function's return type from number to string. Before making the change, what should you do first?

2

What is a characterization test?

3

In a PR description, which section provides the most value to a code reviewer?

4

What is the strict definition of refactoring?

5

Why should you NOT refactor code you don't yet understand?

6

A codebase uses async/await everywhere but you prefer Promise chaining. When contributing, which should you use?

Coding Challenges

1
1

Safe Refactor with Characterization Tests

You are given a 50-line JavaScript function messy-formatter.js that formats user profile data but has inconsistent variable names, inline magic numbers, and a deeply nested conditional. Your task: (1) Write characterization tests covering at least 5 input/output pairs before touching any code — save as formatter.test.js. (2) Refactor the function: extract sub-functions, replace magic numbers with named constants, flatten the nested conditionals. (3) Verify all characterization tests still pass. (4) Write a refactor-notes.md explaining each change and why it's safe. Input: messy-formatter.js provided in the challenge. Output: formatter.test.js, refactored-formatter.js, refactor-notes.md. Time estimate: 25–30 minutes.

Medium

Mini Project

1

First Contribution to a Real Open-Source Project

Find a beginner-friendly open issue (labeled 'good first issue' or 'help wanted') on any active JavaScript or Python project on GitHub. Complete a full contribution cycle: (1) Blast Radius Analysis — before writing a line, document all files affected by your change in impact-analysis.md. (2) Style Audit — read 5 existing functions in the relevant module and document the patterns you'll match (naming, error handling, async style) in style-notes.md. (3) Characterization Tests — write tests covering current behavior before making any change. (4) Implementation — make the change, matching codebase conventions exactly. (5) PR Description — write a complete PR description using the Why/What/Blast Radius/Testing/Migration format. Open the PR (or a draft PR if not confident). Submit links to your impact-analysis.md, style-notes.md, test file, and PR URL.

Hard