7.Leave It Better Than You Found It

The Problem in Real Life

One Big Clever Change vs. A Small, Safe, Reviewed One

Making a Small Change, Testing It, Committing and Opening a Pull Request

• 1. Plan the smallest useful change: write the plan in two or three sentences before coding. Here: a GET /events/:eventId/sales-count endpoint returning { "sold": 4213 }, and a counter on the dashboard that polls it every 10 seconds (polling, Act 23 — simple and reliable; live connections can come later).
• 2. Create a branch (Act 15): git switch -c feature/live-sales-counter.
• 3. Follow the existing patterns: copy the shape of the code you traced: a route with the same requireOrganiser middleware, a short controller, a service function with the same organiser filter, parameterised SQL. New code should look like it was always there. Small extra: a 5-second cache (Act 12, Act 14), so thousands of dashboards polling every 10 seconds don't each hit the database.
• 4. Test it (Act 17): a unit test for the service (counts only paid orders for that event), an integration test for the route (200 with the right number for the owner; 404 for another organiser's event — the authorization rule, tested), and a check by hand in the running app with the debugger. She also fixes the skipped test she found in chapter two — leaving the safety net stronger.
• 5. Check the rest still works: run the whole test suite and the linter (npm test, npm run lint) — the same checks CI will run (Act 19).
• 6. Commit clearly (Act 15): small commits with clear messages saying what and why: feat(sales): add sales-count endpoint for live counter, feat(dashboard): show live sales counter (polls every 10s), test(sales): re-enable skipped export test. Many teams use this "type(scope): summary" style, called Conventional Commits.
• 7. Open a pull request (Acts 18, 24): a clear title, what and why, how to test locally (linking the new README section), screenshots of the counter, and what reviewers should look at carefully (the organiser filter, the cache). Respond to review, wait for CI to pass, merge, deploy (by the careful checklist this time, Act 19), and watch the logs and metrics after release (Act 19, Act 21).
• 8. Leave it better — the README: in a separate, small PR, she adds the repo's first README.md: what it is, how to run it locally (chapter six's steps), the folder map, the entry point and request flow, how to run tests, and known issues (Node 16, manual deploy). Plus the corrected .env.sample.

// routes/sales.js
router.get("/events/:eventId/sales-count", requireOrganiser, salesController.getSalesCount);

// services/salesService.js
exports.getSalesCount = (eventId, organiserId) =>
  cache.wrap(`sales-count:${eventId}:${organiserId}`, 5, () =>   // cache for 5 seconds
    db.query(
      `SELECT COALESCE(SUM(o.quantity), 0) AS sold
         FROM events e
         LEFT JOIN orders o ON o.event_id = e.id AND o.status = 'paid'
        WHERE e.id = $1 AND e.organiser_id = $2          -- same organiser filter
        GROUP BY e.id`,
      [eventId, organiserId]
    ).then((r) => (r.rows.length ? { sold: Number(r.rows[0].sold) } : null))
  );
// controller: if the service returns null (not this organiser's event) -> 404

it("returns 404 for another organiser's event", async () => {
  const token = makeDevToken({ organiserId: "org_other" });
  const res = await request(app)
    .get("/api/events/311/sales-count")
    .set("Authorization", `Bearer ${token}`);
  expect(res.status).toBe(404);   // the query returns nothing for someone else's event
});