주간 업무 - 2023.11w
이름 짓기
개발을 하다보면
'이런 곳에서 시간을 이렇게 써야한다고?'
라는 생각이 드는 부분이 있다.
나만 그런게 아니다나도 생각외로 시간을 보내는 부분이 이름 짓기인데
자연스러운 이름 짓기가 여간 까다로운게 아니다.
이번주에는 흔히들 보는 팝업창에서
'오늘은 보지않기'라던지 '다시는 보지않기'같은 버튼을 누를경우
localStorage에 값을 저장해 해당 기간 동안 팝업을 노출하지 않는
기능을 개발하는 일을 맡았다.
localStorage에 값을 set하고 get해오는 과정은 간단했지만
들어가는 값의 '이름'을 무엇으로 지을지 상당히 고민했다.
localStorage 개발에 나, 강림
사실 localStorage에 기존에 사용하던 팝업 노출 관련 값이 있었다.
xxx(팝업명)_HVB라는 것인데 인수인계에서 부분에서 해당 의미가 유실된건지
뜻을 아는 사람이 아무도 없고 그나마 추측으로 'HaVe Been'(~ 한 적 있는)이라는 뜻으로 좁혀졌다.
문제는 점점 이런 종류의 팝업이 늘어나다보니 localStorage가 점점 XXX_HVB로 도배되고 있었다.
'~동안 보지않기'류 팝업의 추가 개발 당시 해당 값이 하나의 필드에 묶여 관리된 게 아니었기 때문에
확장성을 고려하는 개발도 같이 신경 썼어야 했는데 그런 고려가 안된채로 개발이 이어졌었다.
뒤늦게 localStrorage 관련 개발을 맡은 나는 개선책으로
각 팝업의 '다시 보지않기'에 대한 값을 하나로 묶어
총괄할 수 있는 Object를 만들어 관리하기로 했다.
문제는 Object의 이름을 지을 때
기존의 HVB라는 서사가 없거나 의미가 모호한 표현을 쓰고 싶지 않다는 것이었다.
전임자분도 그래서 그랬었던걸까
현재 앱 정보를 관리하는 Object의 이름은 APP_INFO 라고 관리하고 있다.
그렇다보니 다시 보지않기를 관리하는 Object도
XXX(다시 보지않기)_INFO 라는 형식으로 지으려 했는데
다시 보지않기에 대한 명사형이나 축약어를 짓는게 여간 쉽지않았고
잘못했다간 전의 HVB같은 상황이 될 것 같았다.
구글에 열심히 검색해봐도 도대체 '다시 보지않기'를 매끄럽게 어떻게 풀어야될지 몰라서
팀 내 외국인분에게 팝업같은 곳에서 쓰이는 다시 보지않기를 뭐라고 하나요라 했더니
'Do Not Show Again'이라 하셨다.
아... 아무래도 HVB같은 작명을 피해갈 수는 없을 것 같다.
작은 파도가 너울성 파도가 되지 않도록
값을 관리할 Object의 이름을 DNSA_INFO라 지은 후
수십번을 다시보고 2시간을 고민했었다.(이게 맞을까)
그리고 고민끝에 과장님께 물어봤다
'더 명쾌한 뜻 없으면 어쩔 수 없지... 근데 이거때문에 2시간을 썼어?'
사실 이런 소리를 듣는 것도 당연한게
업무 중 2시간이면 정말 많은 일을 할 수 있는데
이름 짓기에 하루 업무 1/4이나 되는 시간을 썼으니 드릴 말씀이 없긴 했다.
'과장님 뜻을 알 수 없는 HVB부터 시작해서
추가 개발 시 Object에 담아 관리 하지 않다보니 여기까지 와버려서...
신중하게 할 수 밖에 없었슴다... 다시는 이런 일이 재발하지 않도록여...'
내가 localStorage에 있는 값을 새로 추가하는 부분이 신중했던 이유는
localStorage에 한번 추가된 정보는 사용자가 앱을 삭제하지 않는 이상 계속 남아있기 때문이다.
그렇기에 사용자가 앱을 삭제하지 않는 이상 사용하지 않는 localStorage값이 유지된다.
값을 초기화하기 위해 사용자한테 앱을 한번 재설치해달라 할 수도 없는 노릇이고.
localStorage에 값이 저장된다고 에러를 일으키진 않는다.
하지만 값의 관리가 어려워져 유지보수에 시간이 들어가는건 문제고 개선해야한다고 생각한다.
나는 그래서 localStorage에 값을 저장하기 전
어떻게, 어떤 이름으로 저장할 것인가에 대한 시간을 좀 더 투자해 유지보수를 줄이려 했다.
그리고 덤으로 같은 카테고리의 값(다시 보지않기)을 어떻게 관리할 것인지까지.
HVB로 시작된 네이밍의 작은 파도부터
개별로 관리되고 있던 작은 파도까지 모여
갑작스러운 너울성 파도를 일으켰지만 더 이상 큰 파도는 없길 바라면서.
잘 부탁해 DNSA
사실 뜻은 빈약하더라도 HVB는 그것만의 서사가
납득할 수 있게 인수인계 되었다면
Object 네이밍도 HVB_INFO로 지었을 수 있겠지만
인수인계 과정에 해당 히스토리가 유실되었다보니
해당 네이밍의 의미를 부여할 수 없었다.
때문에 팀원들에게 의견을 구할때도
기존 HVB가 무슨 의미인지 모르겠어서
이참에 새로운 뜻으로 바꾸자는 주장에 힘이 실렸던 것 같다.
그러므로 DNSA도 후에 같은 결말을 맞지 않게
인수인계 문서에 설명을 잘 기록해두기로했다.
DNSA(Do Not Show Again. 팀 내 인원에게 허락 다 맡음.)
