Stage 2 — Professional Refactoring

Five Goals Every Developer Should Have

Stage 2 applies five professional practices to Grayson’s original animation. The canvas output is identical to Stage 1 — the moon still drifts, the stars still twinkle, the central star still rotates and pulses. What changed is the code: every bare number has a name, every visual element has its own function, and every function has a document block explaining what it does. This is what production-quality code looks like.

• 1
  Name Your Constants. Replace every bare number with a descriptive const. TWINKLE_SPEED = 0.05 explains itself; bare 0.05 does not. Anyone reading the code — including you, three months from now — immediately knows what to change to make the stars twinkle faster or slower.
• 2
  One Function, One Job. draw() is now a six-line scene recipe. Each scene element (drawStars(), drawMoon(), etc.) lives in its own function. You can comment out drawMoon() and the moon disappears without touching any other code. That is testability in its simplest form.
• 3
  Separate Constants From State. Constants (values that never change) and state variables (values that change every frame) are in clearly labeled sections. CW = 400 never changes. moonX changes 60 times per second. Keeping them separate makes both easier to reason about.
• 4
  Document Every Function. A brief JSDoc block above each function answers: What does this do? and Why does it do it this way? The drawStars() comment explains the randomSeed() trick and the phase-offset technique — two ideas that are invisible without documentation.
• 5
  Fix Your Bugs First. The typo "twinle" is corrected. The undeclared ndx in drawStar() is declared. The leftover comments are removed. These are small fixes — until the code grows, and they become invisible landmines. Make clean code a habit, not a cleanup task.