지난번 읽기 좋은 코드에 대하여 글을 썼었다.
식별자 명이 얼마나 중요한지에 대한 글이었는데 내 경험을 바탕으로 글을 이어나가 보려 한다.
복잡한 로직이 만들어지는 과정
대 혼돈 그 시작
내가 맡은 파트 중 다중 필터링 처리를 해야하는 부분의 개발이 필요했다.
관련하여 열어본 기획서에는 블럭만 처리해놓고 아무런 기획안이 나와있지 않았었다.
꽤나 복잡한 로직에 대한 부분이었고 선임 개발자분과 필터링을 할 때 어떻게 동작할지를 가정하며 동작을 정의 후 기획자에게 정의한 내용을 제시하여 완성되게 된 기능이었다.
길을 잃은 기획안
code complete2를 읽고 있는데, 설계가 얼마나 중요한지에 대해 읽으며 관련 경험을 바탕으로 매우 공감할 수밖에 없었다. 추가 수정은 굉장히 많은 자원을 낭비한다..처음부터 제대로 된 설계가 없으니 계속되는 로직 변경과 추가에 코드는 복잡해져만 갔다. 아마 해당 기능에 있어 기획자들도 복잡한 부분을 잠시 미뤄뒀으리라 생각이 되고, 우리가 제시한 방향을 단번에 이해하지 못해 기획에는 목적성 없이 때에 따라 요청이 변경되었다.
코드가 쌓이며 길을 잃은 변수명
여러차례 기획의 번복으로 어느 새 길을 잃은 내 코드를 발견했다.
새로 추가되는 기획안과 변경되는 내용에(기획자 분들도 길을 잃은듯 하였다.) 이 코드를 내가 수정할 수 있을까라는 두려움 까지도 왔다. 코드가 쌓이면서 리스트의 상태들은 비슷비슷한 이름으로 나를 혼란스럽게 했다.
부끄럽지만 뭘 하나 수정하려면 당최 해당 리스트가 무슨 리스트였는지 알 수가 없어 한참을 추적해야 알아낼 수 있는 지경이었다.
두려움의 원인
꿈에 나올 정도로 스트레스를 받고있었지만 해내야 한다는 그 한 가지 생각에 마음을 가라앉히고 내가 이 코드를 보기 두려운 이유를 찾았다.
- 코드를 제대로 동작시키려면 우선 각자가 하는 역할을 명확히 알아야 한다.
식별자가 무슨 역할을 하는지 찾느라 기운을 다 뺄 정도라면, 식별자를 추적하는 시간 자체를 줄이는 게 가장 먼저 되는 순서라고 생각했다.
여행을 가고싶으니 여행지를 분류하는 필터링을 예로 들어보자 (실제 프로젝트와는 다른 예시입니다)
1. 6대주
2. 나라
3. 나라 혹은 도시를 검색할 수 있는 서치
이렇게 세 가지를 해야 하는데 규칙은 이러하다.
6대주를 선택하면 6대주에 해당하는 두 번째 필터인 나라의 리스트가 추려진다.
=> 유럽을 선택했다면 두번째 필터링에서는 유럽에 속한 국가만 선택할 수 있게 필터링 된다.
자, 여기서 선택할 수 있는 셀렉트 태그 형식의 두 필터의 이름을 지으면서 내가 한 막대한 실수는 이러하다
- 6대주 리스트
- 나라 리스트
으아니 이렇게 간단한데 뭐가 문제냐구?
각 필터의 상관 관계를 고려한 로직의 흐름을 보자.
1. 6대주를 필터링 한다.
2. "나라 리스트"는 6대주 중 선택한 주를 바라보고 필터링하여 해당 국가들을 렌더링 해야한다.
- 여기서 중요한 포인트!! 나라 리스트를 set하면 안된다. 왜냐, 6대주가 디폴트 값이 '전체선택'일 경우 모든 나라를 다시 다 필터링 해야하기 때문이다.한마디로 변질되면 안되니 얕은 복사를 하던 해당 경우의 전용 필터링 리스트를 만들던 해야한다.
3. 6대주가 상위의 개념이므로 나라를 선택 후 6대주를 선택하면 6대주 기준으로 리스트가 나오고 나라는 '전체선택'으로 변경된다.
4. 서치의 경우 6대주가 선택되어있으면 6대주 기준으로 리스트를 그리고 6대주와 나라가 모두 선택되어있는데 선택된 6대주를 검색하면 나라는 리셋되고 6대주가 뜬다.
여기서 눈물의 포인트는 6대주와 나라 모두 전체선택 시 제대로 리스트가 쨘! 하고 나와줘야 하는데 얽히고 섥힌 리스트의 상태 업데이트를 하고 원하는 초기값을 불러오는 과정 등이 정말 어려웠다는 것이다. 초기값 그게 왜 그리 어려웠을까. 바로 나조차도 헷갈려 죽겠는 변수명 때문이었지.
너무나 쉽게 고친 로직
당시에는 명확한 식별자라고 생각해 이름을 부여했던 리스트들이 쌓이고 상생하며 점점 명시성은 모호해져 갔다.
로직을 고치기도 전에 리스트명이 뭘 하는 리스트인지 찾다가 지쳐버릴 즈음 깨달았다. 리스트명만 정리해도 훨씬 쉬워질 것이란 것을.
각 필터링마다 특징이 되는 키워드들을 선별해 한참을 식별자 변경에만 몰두하였다. 그러니 필요 없는 로직도 보이고 코드가 하나 둘 정리가 되어갔다.
그리고 로직을 수정할 때 그동안 날 힘들게만 했던 파트가 맞나 싶을 정도로 손쉽게 해결하였다.
이 때 나는 다시금 식별자명이 얼마나 중요한 역할을 하는지 깨달았고 제대로 지어야 겠다는 다짐을 하게 되었다.
나름 이번 프로젝트를 거치며 나에게 가장 크게 다가온 러닝포인트인 것 같다. 변수명을 제대로 지으면 코드도 깔끔해지고 내 코드를 더이상 두려워 하지 않아도 된다.
수정하기 전의 내 코드는 마치 엉켜버린 실 같았다. 한 번 숨을 고르고 변수명을 풀어나가는 과정에서 정말 큰 깨달음을 얻었다.
해당 이슈를 계기로 다른 사람이 혹은 미래의 내가 봤을 때도 명확할까를 고민하며 지으려 노력하게 되었다. 그리고 틈이 날 때마다 부끄러운 식별자명들을 퇴치하고 언제 그랬냐는듯 보다 나은 식별자명을 데려다 앉혀놓는다!
