uoo

핵심 기여

개요

문제와 해결

반복 스크립트의 복사를 모듈 조합으로 바꾸기

문제. 캐릭터별 회복과 장비, 대상 선택 코드가 복사되면 공통 동작을 바꿀 때 일부 스크립트만 다른 상태로 남을 수 있습니다.

판단. 공통 동작과 기본 설정은 모듈에 두고 캐릭터별 차이는 레시피가 정하도록 나눴습니다. 실행 환경은 원래처럼 단일 Razor 파일을 받도록 유지했습니다.

flowchart LR
    Modules["공통 모듈: 설정과 동작"] --> Builder["Node.js 조립기"]
    Recipe["레시피: 순서와 설정 변경"] --> Builder
    Builder --> Script["실행할 단일 Razor 파일"]
    Builder --> Settings["설정값과 참조 위치"]

구현. 모듈의 config, timer, state, setup과 loop 같은 구간을 읽고 레시피 순서로 조합했습니다. 일회성 루틴과 반복 루프는 같은 모듈 형식 안에서 생성 범위를 달리했습니다.

결과. 공통 코드는 한 곳에서 고치고 각 캐릭터의 차이는 선언된 조합과 값으로 읽을 수 있게 했습니다. 생성물에는 원본 모듈의 출처도 남겼습니다.

공유 변수의 주인과 사용하는 곳을 확인하기

문제. 여러 모듈이 같은 설정이나 상태 이름을 선언하거나 필요한 모듈 없이 변수를 읽으면 실행 파일만 보고 원인을 찾기 어렵습니다.

판단. 변수마다 한 모듈을 소유자로 두고 선언과 참조를 조립 전에 검사했습니다.

const owner = new Map();
for (const [ident, module] of modules) {
  for (const name of module.declared.keys()) {
    if (owner.has(name)) {
      throw new BuildError(
        `${name} is declared by both ${modulePath(owner.get(name))}`
        + ` and ${modulePath(ident)}. A name belongs to one module`
      );
    }
    owner.set(name, ident);
  }
}

구현. 미선언 변수와 빠진 모듈 참조도 검사했습니다. 설정을 변경한 레시피에서는 해당 설정의 소유 모듈이 실제 조합에 있는지 확인했습니다.

결과. 조합의 오류를 모듈과 레시피의 위치를 가리키는 메시지로 확인할 수 있도록 했습니다. 이 검사는 선언과 참조의 계약을 다루며 게임 안에서의 모든 동작을 검증하는 범위와는 구분했습니다.

설정값과 바꾼 이유를 함께 남기기

문제. 결과 파일의 숫자만 보면 기본값인지 특정 캐릭터를 위한 변경인지 알기 어렵습니다. 공통 모듈이 설정을 읽는 곳도 함께 추적할 필요가 있었습니다.

판단. 레시피에 변경 이유를 남기고 조립기가 설정 설명과 참조 위치를 함께 보여 주도록 만들었습니다.

구현. --settings는 설정값, 의미와 참조 모듈, 파일 위치를 보여 줍니다. --check는 레시피와 생성물이 현재 원본에서 만들어진 내용과 같은지 비교합니다. 문서는 게임 메커니즘과 캐릭터 구성, 개별 루프를 나눠 기록했습니다.

결과. 코드 변경과 설정의 판단 이유를 함께 보관했습니다. 조건부 시뮬레이션도 별도로 두고 공식 수치와 가정, 실제 관찰의 차이를 구분했습니다.

결과와 확인 범위

취미 도메인에서 반복 코드, 공유 상태와 설정의 추적 문제를 직접 풀어 본 사례입니다. 게임 클라이언트나 Razor 자체를 만든 성과로 설명하지 않았습니다. 게임 내 승률이나 외부 사용자 수는 성과 지표로 추가하지 않았습니다.