[책 후기] 내 코드가 그렇게 이상한가요?

이미지: 교보문고

 

• 저자: 센바 다이야
• 출판사: 인사이트
• 책 링크: https://product.kyobobook.co.kr/detail/S000202521361 

 

---

1. 읽게 된 계기

친구들과 하는, 주에 한 번씩 모이는 스터디가 있다. 독서를 할 때도 있고 처음 보는 기술을 맛보기 할 때도 있는데, 저번에는 '내 코드가 그렇게 이상한가요?'를 읽기로 했다. 책 제목부터 모두의 호기심을 잡아끌어서 만장일치로 책이 결정되었다. 내 코드가 이상한 이유는 뭘까? 본 글에서는 책을 읽으면서 이야기했던 내용들이나 인상 깊었던 내용들 위주로 정리해보고자 한다. 

 

 

 

---

2. 책을 읽고

책을 읽고 요약한 것은 깃허브에 메모해두었다.

 

 

이 책은 굉장히 친절하다. 다른 책에서는 이론적인 개념과 코드를 보여주는데 그친다면, 이 책에서는 어떠한 개념에 대해 글로 쉽게 설명하기 위해 좀 더 많은 예제를 보여주려고 노력한 것이 보인다. 여러 문제를 일으킬 수 있는, 복잡한 코드를 악마를 불러일으킨다고 표현되는데, 그 표현이 웃겨서 스터디 때 서로의 코드를 보며 악마 소환자라며 장난치기도 했다. 가볍게 읽을 수 있으면서도 중요한 내용이 쏙쏙 담겨있어서 재미있게 읽었다.

 

공감 가는 내용도 많았고, 나와는 생각이 다른 부분도 꽤 있었다. 하단에는 그중 몇 가지를 꼽아서 서술해보려고 한다.

 

 

💎 DRY; Don't Repeat Yourself

DRY 원칙은 말 그대로 반복하지 말라는 뜻이다. 이 책에서는 이와 더불어 '중복을 금지하라는 의미가 아니다. 같은 로직처럼 보여도 개념이 다르면 중복을 허용해야 한다'라고 말한다. 이 부분에 정말 큰 공감을 했다.

 

개발을 하다 보면 IntelliJ나 소나큐브가 노란 줄을 띄우며 이건 요렇게 고쳐~ 요건 저런 문제가 발생할 수 있어! 이런 식의 힌트를 주곤 한다. 난 대부분 이 힌트를 수용하는 편이지만, 딱 한 가지 중복 코드에 대한 힌트는 곧잘 무시하는 편이다. 보기에는 같은 코드이지만 다른 의미로 사용되는 코드가 대부분이었으며, 나는 이 경우에는 중복이라고 생각하지 않는다.

 

단순히 코드의 생김새가 같다고 메서드를 추출하여 중복 로직을 제거하면, 이후 리팩터링할 때 고려할 사항이 많아져 복잡함을 가증시켰다. 또, 단순히 생김새만 같았을 뿐 코드의 목적이 달랐으니 다른 요구사항이 추가되어 결국 다른 형태의 코드가 만들어지는 경우도 있었다.

 

 

💎 이름 설계

• 최대한 구체적이고, 의미 범위고 좁고, 특화된 이름
• 존재보다는 목적 기반의 이름
• 소리 내어 말해보기

책을 읽었을 때는 음음 그렇지, 그러면 좋지. 하면서 읽었는데 변수 네이밍과 관련해서 최근 팀원이랑 대화한 내용이 떠올라서 적어본다.

 

매직 넘버를 상수화할 때 이름에 대한 고민이었는데, 상수 이름에 값을 넣는 것에 어떻게 생각하는지에 대한 질문을 들었다. 처음 들었을 때는 값을 변경할 때 변수명도 같이 변경해야 하지 않느냐, 불편할 것 같다는 답변을 했다. 그런데 팀원분이 수정하는 사람이 한번 고생하면 읽는 사람은 훨씬 편해진다고 말씀해 주셨는데 처음엔 읽는 사람이 값을 신경 쓸 필요가 없도록 변수명을 잘 지어야 하지 않나?라는 의문이 들었다가 코드를 읽고 바로 이해했다.

 

예제를 한번 만들어보았다. color 별로 분기되는 로직이 있다. 이 color라는 값은 항상 존재해야 하는 값으로, 존재하지 않으면 default 값을 이용하면 된다. 그렇다면 아래와 같이 DEFAULT_COLOR라는 상수를 정의할 수 있다. mix()라는 메서드를 통해 아래와 같이 색상을 섞는 로직이 있다고 가정해 보자.

public class Yellow {

    private static final String DEFAULT_COLOR = "BLACK";
    
    public String mix(String color) {
        if(StringUtils.isEmpty(color)) {
            color = DEFAULT_COLOR;
        }
        if("BLACK".equals(color)) {
            return "BLACK";
        }
        if("BLUE".equals(color)) {
            return "GREEN";
        }
        if("RED".equals(color)) {
            return "ORANGE";
        }
        throw new IllegalArgumentException("지원하지 않는 색상입니다.");
    }
}

 

 

내가 위 로직을 읽는 순서는 이랬다.

1. color가 빈 값이면 DEFAULT_COLOR라는 값을 세팅한다.
2. color가 "BLACK"이면 "BLACK"을 반환한다.
3. 어? 그러면 DEFAULT_COLOR 세팅한 경우엔 color가 어떤 값이지? 
4. DEFAULT_COLOR를 클릭해서 어떤 값이 저장되어 있는지 확인한다.

 

만약 DEFAULT_COLOR가 아니라 DEFAULT_COLOR_BLACK이었다면 3~4번 과정을 거치지 않았을 것이다. 읽는 사람 입장에서는 로직을 읽는 속도가 훨씬 편해진다. 다만 이것도 문제가 있다. 만약 누군가가 아래와 같이 변수명은 수정하지 않고, 값만 수정한다면? 

private static final String DEFAULT_COLOR_BLACK = "BLUE";

읽는 사람 입장에서는 당연히 BLACK일거라 생각했는데 실제 저장된 값과는 다르니 로직을 잘못 이해할 가능성이 커진다. 이런 경우는 코드 리뷰를 통해서 방지할 수 있긴 하겠지만 코드 리뷰 때 놓치거나 에러 나기 십상이기도 하다. 아무리 모든 일은 트레이드 오프라지만 요 문제는 선택하기 좀 더 어려운 일 같다. 하지만 비즈니스 로직은 너무나도 복잡하고 긴 로직이 포함된 경우가 많았고, 상수 값을 확인하느라 계속 왔다 갔다 할 바에는 코드 리뷰를 더 꼼꼼하게 하는 편이 좋지 않을까,라는 생각도 들었다.

 

 

💎 나쁜 구조는 바로바로 개선하자

나쁜 구조가 눈에 띄면 조금씩이라도 좋으니 개선하는 습관을 기르자. 나쁜 코드가 존재하면 새로 짠 내 코드와 비교하며 '저거보단 낫지..'라는 생각을 하거나, '원래 이렇게 되어있었으니 괜찮다'라는 생각을 할 수 있게 된다는 글이 있었다. 개인적으로는 크게 공감했다. 기존 코드를 복사+붙여 넣기 하면 기능이 동작은 하겠지만 이런 코드가 쌓이다 보면 거대한 레거시 코드가 재생산되는 것 같다. 발전은 없고 돌아만 가는 코드를 유지하면 다신 꼴도 보기 싫은, 건드리기 싫은 코드로 남는 것 같다.

 

물론 비즈니스 코드가 굉장히 복잡한 것은 충분히 이해하고도 남는다. 기존 코드를 제대로 이해하지 못하고 복사 붙여 넣기만 했다면 어떠한 결함이 존재하는지 몰라서 불안하기도 하고, 누군가 이 코드에 대해 왜 이렇게 짰는지 물어본다면 기존 코드를 그대로 가져다 사용했다는 답변이 타인에게 책임을 미루는 것처럼 느껴져서 스스로가 부끄러웠다. 기존 코드를 제대로 이해했다면 조금이라도 리팩터링 가능할 것 같아서 잘 실천하려고 노력해야겠다는 생각이 들었다.

 

 

💎 무작정 다수결로 설계 규칙을 만들지 마라

설계 역량이 뛰어난 팀원이 중심이 되어 규칙을 세우는 방법도 있다. 개인적으로는 신선한 충격으로 다가왔다. 일반적으로 커뮤니케이션 관련된 책을 읽다 보면 모두의 찬성을 이끌어낼 수 있는 의견이 이상적이라고 한다. 하지만 현실적으로 매번 모두의 찬성을 이끌어내는 것이 힘드니 다수결로 가곤 한다. 하지만 이 책은 다른 이야기를 한다. 다른 사람들이 반대하더라도 뛰어난 팀원 한 명이 주도해서 일을 진행할 수도 있다고 말한다.

 

그 이유는 즉슨, 모두의 의견을 설득하려다 보면 수준이 낮은 쪽에 하향평준화될 수 있다. 물론 설계 규칙의 의도가 한 번에 전달되기는 힘드니, 리뷰와 스터디 등을 통해 어떤 의도를 갖고 설계한 것인지 끊임없이 전달해야 하고, 모든 팀원의 설계 역량이 어느 정도 수준 이상이 되면 그때 다시 설계 규칙에 대해 논의할 수 있다고 말한다.

 

처음에는 우리 팀에서 실력이 부족하다 하면 주로 나이기 때문에 하향평준화라는 말에 살짝 마음의 상처를 받았지만(ㅋㅋㅋ) 팀원의 실력을 끌어올리면서도 일관된 설계 규칙을 가질 수 있는 좋은 방법이라는 생각이 들었다. 다만 어떤 의도를 갖고 설계한 것인지 끊임없이 전달해야 한다는 점에서 총대를 맨 팀원은 굉장히 번거롭고 괴로울 수 있다는 점이 치명적인 것 같다. 

 

 

 

---

3. 마무리하며

 

초반에는 다소 뻔하게 시작해서 개발을 시작한 지 오래되지 않은 사람들이 주 독자층인가?라는 생각이 들었는데 읽다 보니 다양한 이야기를 들을 수 있어서 좋았다. 익숙한 이야기들도 있었고, 처음 들어보는 이야기도 있었는데 쉽게 풀어써주었기 때문에 포기하지 않고 끝까지 읽을 수 있었다. 사실 소프트웨어 품질과 설계 쪽에서 전부를 이해하거나 공감하지는 못했지만, 좀 더 경험이 쌓인 뒤에 보면 다르게 느껴지리라 믿는다. 

 

이 글에 쓰인 내용뿐만 아니라 더 다양한 소재를 재미있게 풀어쓰니 관심 있으신 분들이라면 직접 읽어보시는 것을 추천드립니다!😄

 

 

(+)

해당 포스팅 내 사용한 이미지들은 flaticon에서 다운 받았습니다.