프로젝트 중반에 빌드 담당을 맡았다. 테스터가 쓸 앱을 매일 만들어 올리는 일이다. 안 만들어지면 원인을 찾는다. 처음에는 잡일이라고 생각했다.
Table of contents
Open Table of contents
매일 아침의 일
svn update 로 최신 코드를 받고 ndk-build 와 Eclipse 빌드를 돌린다. 실패하면 원인을 찾는다. 성공하면 APK 를 기기에 설치해 켜지는지 보고 공유 폴더에 올려 알린다. 잘 되면 30분이고 안 되면 오전이 다 갔다.
깨지는 이유가 정해져 있었다
몇 주 하니 깨지는 이유가 몇 가지로 정해져 있다는 것이 보였다.
새 .cpp 를 만들고 Android.mk 의 LOCAL_SRC_FILES 에 안 넣으면 그 사람 컴퓨터에서만 된다. 리소스 이름이 겹치면 나중 것이 이겨서 화면 하나가 엉뚱한 그림으로 나온다. 아직 안 끝난 코드를 올리면 컴파일은 되는데 켜자마자 죽는다.
제일 찾기 어려웠던 것은 새 파일을 svn add 안 하고 커밋한 경우다. 올린 사람 컴퓨터에는 있으니 잘 돌고 받는 쪽에만 없다. svn status 에 ? 로 떠 있는데 자기 화면에서는 그냥 넘어간다.
변경 목록부터 읽었다
처음에는 오류 메시지를 읽고 그 파일을 열었다. 오류가 나는 파일과 원인이 있는 파일이 다른 경우가 많았다.
방법을 바꿨다. 어제는 됐는데 오늘은 안 된다는 데서 출발한다. svn log 로 어제와 오늘 사이를 보고 관계있어 보이는 것을 되돌려 본다. 코드를 읽는 것보다 변경 목록을 읽는 것이 먼저였다. 커밋이 많은 날은 리비전을 절반씩 잘라 svn up -r 로 확인했다.
매일 하니 다른 것도 보였다. 금요일 빌드가 자주 깨진다. 여러 명이 같은 파일을 고친 날은 거의 항상 깨진다. 며칠 안 깨지면 그다음이 크게 깨진다. 마지막 것 때문에 자주 빌드하는 것이 낫다는 것을 알았다. 매일 하면 하루치만 보면 된다.
사람에게 말하는 방식을 바꿨다
기술적인 것보다 이것이 어려웠다. 빌드가 깨지면 누가 무엇을 잘못했는지 알게 된다. 그것을 어떻게 말할지가 문제였다.
처음에는 누구 코드에서 깨졌다고 말했다. 몇 번 하고 나니 그 방식이 안 좋다는 것을 느꼈다. 사람을 지목하면 방어하게 되고 원인 찾는 것이 늦어진다.
지금 빌드가 이 파일에서 안 되고 최근 변경 중 이 부분이 관련 있어 보인다고 말하는 것으로 바꿨다. 같은 내용인데 반응이 달랐다. 누가 깼느냐가 아니라 무엇이 안 되느냐로 말하니 다들 자기 것부터 확인해 줬다.
정리
- 빌드가 깨지는 이유는 몇 가지로 정해져 있다
LOCAL_SRC_FILES누락과 이름 충돌과 미완성 코드가 그것이다svn add를 빠뜨린 커밋은 올린 쪽에서만 돌아 제일 찾기 어렵다- 오류 메시지가 가리키는 파일과 원인이 있는 파일은 다를 때가 많다
- 코드를 읽기 전에
svn log로 변경 목록을 읽는다 - 커밋이 많으면 리비전을 절반씩 잘라 확인한다
- 자주 빌드하면 볼 범위가 좁아진다
- 누가 깼느냐가 아니라 무엇이 안 되느냐로 말한다