Skip to content

Module 6 — Bringing it together & Project A

Estimated: 1 week · Syllabus · ← Module 5

  • Cross-cutting principles, now with the theory behind them:
    • DRY — a single source of truth for each piece of knowledge; but beware premature abstraction (wrong abstraction costs more than duplication).
    • YAGNI — don’t build for imagined futures; complexity you add “just in case” is pure accidental complexity.
    • Separation of concerns / single responsibility — each unit has one reason to change.
    • Principle of least astonishment — code should behave the way a reader expects.
  • Technical debt as a deliberate, tracked tradeoff — not an accident. Sometimes you take a shortcut on purpose and write it down.
  • Refactoring as disciplined, behavior-preserving change under test coverage — the payoff of Module 5.
  • Documentation tiers: README (orientation), inline comments (why, not what), ADRs (decisions), specs (contracts). Each serves a different reader.

Run Project A (the 3D viewer) through the entire pipeline you’ve learned: design doc + non-goals → scaffold (Vite + React + TypeScript + R3F) with locked deps → spec the linking model as a schema + CLAUDE.md → build in vertical slices with clean commits → tests + CI → tag a release. This is the graduation exercise — the same rigor, now self-directed.

Apply the theory where 3D makes it concrete:

  • Information hiding / Parnas: isolate the volatile decisions behind interfaces — the rendering layer (Three.js today, maybe Babylon later), the IFC parser, and the analysis-model adapter (ETABS vs. SAP2000 vs. RAM) should each sit behind a boundary so swapping one doesn’t ripple. The linking model — the stable shared ID tying geometry ↔ analysis ↔ markup — is the highest-value abstraction; design it first.
  • Vertical slices: slice 1 = load and orbit a static model; slice 2 = pick an element and read its ID; slice 3 = attach a markup; slice 4 = link a markup to an analysis result. Each slice works end-to-end.
  • Testing the untestable-looking: you can’t easily unit-test a rendered scene, but you can test the pure logic — the ID mapping, the markup data model, the analysis-import parser. Push logic out of the render layer specifically so it’s testable (which is also good architecture). E2E-test interactions with Playwright.
  • YAGNI check: resist building a general BIM platform. v1 loads one model type and links one analysis source.

☐ Project A shipped to a tagged v0.1.0 with a green CI badge — loading a model, marking up an element, and linking it to an analysis value — and a revised answer to Module 0’s “what makes code good?” Compare it to your first.

(working notes go here)