주간 업무 - 2023.09w
앱 번역 마무리와 문제에 대한 접근 방식
주간업무 8w의 폰트 이슈는 아주 간단히 해결되었다.
NotoSansCJK를 대체할 NotoSansJP를 발견한 것이다.
NotoSansCJK에 비하면 용량이 무려 1/5였다. (CJK가 패키지라면 JP는 단품같은 느낌!)
덕분에 반짝거리며 폰트 로딩이 지연되던 이슈가 말끔히 해결됐다.
이제 프로젝트가 막바지를 향해가는데 특별한 이슈는 없다.
그래서 이번주는 개발 외 부분을 다뤄보려 한다.
어디서 어떻게 처리할까요?
다른분이 맡은 아주 간단한 수정 1건이 있었다.
DB에서 보내주는 텍스트에 \n이라는 개행 표기가 들어갔는데,
개행이 이슈가 되어 막아야하는 수정이었다.
로직이나 프로세스가 들어간 개발도 아니고
에러도 나지 않았지만
그 개발이 이루어진 과정을 보고
내가 개입을 하게되었다. (코드 수정은 아니었다.)
왜 개입을 했냐하면 그 개발에는
내가 항상 체크하는 부분이 빠져있었다.
'어디서 어떻게 처리할까요?'
각자의 방법
위 이슈는
백에서 처리할 경우 \n이라는 문자만 지우면 된다.
그리고 프론트에서 처리하게 된다면,
문자를 지우는 일은 아주 간단하다.
백에서 해당 텍스트 string을 전달받으면
replace()함수와 정규식 표현을 사용해
string.replace('\n'g, '');
텍스트 가공 시 이 한 줄의 코드만 넣어주면 되는 것이다.
둘 다 처리방법은 간단하지만
'어디서 어떻게 처리할까요?'에 따라
개발 방법이 달라질 것이다.
문제는 위에서 언급한 개발에 '어디서 어떻게 처리할까요'라는
선행과제가 해결되지 않았기 때문에
나는 개입을 하게 되었다.
얘! 브런치쟁이들은 이런거 몰라 임마!문제 앞의 나였다면
개입을 하게 된 후 정리를 해봤다.
'DB에서 보내주는 텍스트에 \n이라는 개행 표기를 제거하는 개발'
을 접했을 때
DB에서 보내주는 텍스트 = 백엔드에서 보내주는 텍스트를
\n이라는 개행을 제거 = 백엔드, 프론트엔드 모두에서 처리할 수 있군!
이라는 생각으로 접근하게 된다.
그리고 기존에 \n을 제거하는 방식의 프로세스를 찾아보고
어떻게 처리하고있는지 확인한다.
적당한 선에서 정리
다른 파일들의 기존 프로세스를 확인해보니
백에서 그대로 쓰는 경우도 있고 프론트에서 처리하는 경우도 있었다
나중에 논의가 필요하겠지만
한 곳(백 or 프론트)에서 처리하는 것도 좋지 않을까?
이건 문자가 넘어오는 케이스에 따라
처리 방법이 다를 것 같아 체크를 해봐야한다.
(당장 필요한 부분이 아니기 때문에 생각에서 멈췄다.)
생각과 기존 자료를 바탕으로 백엔드 개발자분과
의논하기 위한 말을 준비했다.
'지금 DB에서 보내주는 텍스트 중에 \n을 제거해야 하는데,
프론트에서 처리할까요? 아님 백에서 처리해서 넘겨주시나요?
기존에는 백에서 or 프론트에서 처리하고 있었습니다.'
그리고 상대방을 배려하는 마음으로 한 마디만 더
'만약 백에서 처리하기 어려우면 프론트에서 처리 할게요!'
딜 교환 후
백엔드 개발자분과 '어디서 어떻게 처리할까요'를 의논한 결과
백엔드 개발자분이 문자 내 \n을 빼주기로 하셨다.
그리고 프론트의 replace() 처리 코드는 제거 되었다.
여기까지만 보면,
간단한 코드에 왜 이렇게까지?
라고 할수도 있겠지만
회사는 서로 다른 개인이 같이 모여 일하는 곳인데
그럼 그 다른 개인을 묶어주기 위한 회사의 룰이 있을테고
그렇다면 서로 다른 개인이 그 룰에 맞게 개발을 해야한다고 생각한다.
룰에 맞게 코드를 개발하기 위해
이 코드가 어떤 위치에서 어떤 의미를 가져야하는지
또한 그것이 그 위치와 의미가 정당한지
많은 부분을 따져야한다고 생각한다.
때문에 서로의 의견을 교환하고 그 의견들에 따라
위치, 의미, 정당함을 찾아가는 과정을 거치다보면
불필요한 코드가 걸러지고 좋은 코드가 완성된다.
중꺾논(중요한건 꺾이지 않는 의논)
위의 과정들로 보아 알 수 있겠지만
내가 개입한 이유는 코드가 잘못되거나 틀려서가 아니다.
개발 전 의논이 없어서이다.
의논을 통해 검증한 1줄짜리 간단한 코드는
백엔드 개발자분이 처리해주시면 프론트에서 넣지 않아도 되는 코드였다.
아마 의논을 거쳤다면 시간(개발 + 검수 + 원복)을
다른 곳에 쓸 수 있었을 것이다.
나는 보통 개발 전에
개발 방법에 대한 충분한 생각과 그렇게 생각한 근거를 준비하고
같이 일하는 동료들과 그에 대한 의견을 나눈다.
준비부터 교환까지 길어야 10분도 안걸린다.
나는 아직 많은 걸 볼줄은 모르지만
어쩌면 일하는 동료간의 커뮤니케이션이
개발 시간도 단축시키고
개발 퀄리티도 높이는 길
이 아닐까 생각한다.
그리고 동료간의 커뮤니케이션으로
아웃풋이 잘 나온 사례를 계속 접하고 있다보니
생각은 확신으로 굳어지긴 했다.
간단한 문제라도 서로 나눠보는건 어떨까?
