화면 이름과 코드 이름의 통일

기획 쪽에서 부르는 이름과 코드의 클래스 이름이 서로 다른 것을 여러 군데에서 보게 됐다. 대화에서 나온 이름으로 코드를 grep 하려면 매번 머릿속에서 한 번 번역해야 했다.

Table of contents

세 벌로 갈린 이름

정리해 보니 이름이 세 벌이었다.

화면·기획   강의실
코드        LearningSpace
DB          tb_class_room

회의에서 「강의실 목록에 정렬을 추가해 주세요」를 들으면 LearningSpace 를 찾고 그 안에서 tb_class_room 을 봐야 했다.

번역을 매번 한다는 것은 매번 틀릴 수 있다는 뜻이기도 했다. 실제로 비슷한 이름의 다른 대상과 헷갈려서 엉뚱한 코드를 열어 본 일이 있었다.

대응표와 기준 정하기

먼저 지금 상태를 표로 적었다.

화면        코드                DB
강의실      LearningSpace       tb_class_room
수강생      Learner             tb_student
과정        Curriculum          tb_course
평가        Assessment          tb_exam

넷 다 달랐고 표를 만드는 데 반나절이 걸렸다. 그것만으로도 도움이 됐지만 표를 계속 봐야 하는 것 자체가 비용이었다.

어느 쪽에 맞출지는 셋을 놓고 따져 정했다.

화면 이름에 맞춘다   회의에서 쓰는 말이다. 사람이 많다
코드 이름에 맞춘다   고칠 곳이 적다
DB 이름에 맞춘다     가장 안 바뀐다

LearningSpace 에 맞추면 대화하는 사람들이 매번 번역해야 하고 그 비용이 더 커서 화면 이름을 기준으로 삼았다.

코드부터 바꾼다

바꾸는 순서는 코드를 먼저 잡았는데 이름을 바꾸는 도구가 대부분의 참조를 함께 따라가 주기 때문이다. 다만 new $className 이나 class_exists 처럼 문자열로 클래스를 부르는 자리는 그 도구가 못 잡는다는 것을 알고 있어야 했다.

그런 자리를 grep 으로 따로 찾아서 손으로 고쳤고 그 목록을 표에 함께 적어 뒀다. 다음에 또 이름을 바꿀 일이 있으면 같은 자리를 다시 찾아야 하기 때문이다.

DB는 모델에서 흡수

MySQL 표 이름은 바로 바꾸지 않았다. RENAME TABLE 자체는 자료를 옮기지 않고 원자적으로 끝나지만 그 표를 부르는 코드가 함께 바뀌어야 해서 그 사이를 메울 중단 시간이 필요했다. 대신 모델 쪽에서 새 이름을 쓰고 실제 표 이름은 모델의 표명 속성 한 줄에만 남게 했다.

이렇게 하면 코드를 읽는 사람은 새 이름만 보게 되고 옛 이름은 한 곳에만 남는다. 왜 다른지를 그 자리에 적어 두는 것이 나중에 바꿀 때의 출발점이 됐다.

새로 만드는 것부터와 용어집의 쓰임

옛것을 전부 못 바꿔도 새로 만드는 것부터는 정한 이름을 지키게 했다. 그러지 않으면 정리하는 속도보다 어긋나는 속도가 빨라진다.

정리한 표는 그 뒤에 다른 자리에서도 쓰였는데 연동 규격을 쓸 때와 새로 온 사람에게 설명할 때였다. 이름을 맞추려고 만든 것이 그 자체로 문서 하나가 된 셈이었다.

정리

• 화면과 코드와 MySQL 이름이 다르면 매번 번역해야 한다
• 번역을 매번 한다는 것은 매번 틀릴 수 있다는 뜻이다
• 먼저 지금 상태를 표로 적는다
• 이야기할 때 쓰는 말을 기준으로 삼는다
• 코드부터 바꾸되 new $className 자리는 grep 으로 찾는다
• MySQL 표명은 나중에 바꾸고 모델에서 흡수한다
• 옛것을 다 못 바꿔도 새로 만드는 것부터 지킨다
• 용어집은 연동 규격과 안내 문서에도 쓰인다