여둘까 Office Layout TIL 11
고치면 다른 데가 터졌다
저장이 안 되는 걸 고치고 나면 왼쪽 드래그가 이상해지고, 그걸 고치면 또 다른 게 안 됐다. 앱 전체가 app.js 한 파일, 2491줄에 들어 있었다.
앞선 TIL 10에서 그 끝에 점검부터 부탁했고, 명령 하나로 브라우저를 띄워 저장·배치·측정·내보내기까지 마흔 가지를 훑는 자동 점검이 생겼다. 돌아보면 이 순서가 이후 모든 걸 정했다. 무엇을 고치든 “고친 뒤에도 나머지가 그대로인가”를 사람 눈이 아니라 점검이 답해 주게 됐다.
갈아엎을지, 나눌지
React로 갈아타는 안을 보고받고 접었다
한 파일이 너무 크니 두 가지 길이 있었다. 하나는 react-konva(React — 화면을 상태에 맞춰 자동으로 다시 그려 주는 라이브러리 — 위에서 캔버스를 다루게 해 주는 도구)로 옮기는 것, 다른 하나는 지금 구조 그대로 파일만 기능별로 나누는 것이다.
react-konva가 지금보다 왜 필요한지 보고해 달라고 했다. 얻는 건 분명했다. 지금은 값을 바꾸면 화면을 손으로 다시 그리라고 불러야 하는데, 이걸 빠뜨려서 생긴 버그가 이번 주에만 셋이었다. React는 그걸 자동으로 해 준다.
치르는 값도 분명했다. 지금은 빌드(코드를 배포용으로 한 번 변환하는 과정) 없이 파일을 그대로 올리는 구조인데 그게 생긴다. 사실상 다시 쓰는 규모다. 캔버스를 직접 다루는 부분은 감싸는 코드가 더 필요하고, 성능은 나아지지 않는다.
그래서 이번엔 옮기지 않기로 하고, 그 이유를 백로그에 적어 두게 했다. 대신 상태를 한곳에 모으고 파일을 나누면 같은 종류의 버그를 훨씬 싸게 상당 부분 막을 수 있다. “언젠가는 옮길지도”로 남겨 두지 않고 근거까지 적어 둔 건, 다음에 같은 고민을 처음부터 다시 하지 않기 위해서다.
나누기 전에 규칙부터 정했다
나누기로 하고 세 가지를 먼저 못 박았다.
- 새 브랜치(원본을 건드리지 않고 따로 작업하는 갈래)에서 계획을 세우고 진행한다
- 끝까지 가되 단계마다 커밋한다
- 동작이 전부 정상이면 그때 합친다
단계마다 커밋하라고 한 건 되돌아갈 자리를 남기기 위해서다. 열두 단계로 나눠 옮기며 단계마다 점검을 돌렸고, 화면이 아예 안 뜨는 실수가 한 번 나왔지만 그 단계 안에서 바로 잡혔다. 몰아서 옮겼다면 어디서 깨졌는지부터 되짚어야 했을 것이다.
“전부 정상이면 합친다”는 조건은 리팩터(동작은 그대로 두고 코드 구조만 고치는 일)에서 가장 중요한 한 줄이었다. 리팩터가 약속하는 건 좋은 구조가 아니라 “바뀐 게 없다”는 것이고, 그 근거를 매번 남길 수 있어야 한다. 근거를 만들 수 없으면 규모를 줄이거나 미루는 게 맞다.
나누며 알게 된 원리
견적은 “몇 개로 쪼갤까”가 아니라 “몇 개를 함께 쓰나”로 낸다
파일이 하나일 때는 어느 줄에서든 값을 바꿀 수 있다. 나누는 순간 “누가 이 값을 바꿀 수 있나”가 정해야 하는 문제가 된다. 자바스크립트는 이걸 언어 차원에서 막는다 — 다른 파일에서 가져온 값에는 다시 대입할 수 없다.
그래서 나누는 일의 첫 단계는 파일을 만드는 게 아니라, 여러 곳에서 바꿔 쓰는 값(공유 상태)을 한 객체에 모으는 것이었다. 이것만 끝나면 파일은 아직 하나여도 이미 나눌 수 있는 모양이 된다. 이런 값이 스물여덟 개였다. 파일 개수보다 이 숫자가 실제 일감에 가깝다.
순환 참조는 조건이 맞으면 허용하고, 이유를 적어 둔다
순환 참조는 두 파일이 서로를 불러 쓰는 구조다. 보통은 피하라고 배운다. 그런데 이 앱에서는 도형을 만드는 쪽, 선택을 다루는 쪽, 실행취소를 쌓는 쪽이 원래 서로를 부른다. 이걸 한 방향으로 펴려면 중간 장치를 새로 들여야 해서 이 규모에서는 더 비싸다.
파일을 읽어들이는 순간에 서로의 값을 꺼내 쓰지만 않으면 순환은 안전하다. 그래서 허용하되 그 이유를 문서에 적어 두기로 했다. 안 적어 두면 다음에 코드를 보는 쪽은 그걸 실수로 읽고 고치려 든다. “금기”로 배운 규칙도 성립 조건을 알면 선택지가 되지만, 어기기로 했으면 근거를 남겨야 한다.