왜 그렇게 짰어?

늘 하는 고민이 있다. 이 코드는 여기에 있어야 할까? 아니면 저쪽에 있어야 할까? 저쪽에 있어도 좋아보이고 이쪽에 있어도 좋아보이고... 이러한 고민을 늘 했었다. 즉, 왜 이렇게 짰는지에 대한 기준이 없었다. 기준이 없기에 난 일관되지 않는 코드를 짜고 있었다. 하지만 켄트 벡의 구현 패턴 책을 읽고 그 기준이 될 수 있는 요소들에 대해 알게 되었다. 가치와 원칙 그리고 패턴이 그것이다.

가치

가치는 사회전체, 회사, 팀 혹은 일부 팀원 등 사회구성원들이 일반적으로 가치있다고 느끼는 것이다. 캔트백은 이 가치를 크게 3가지로 보고 있다.

• 커뮤니케이션
• 단순성
• 유연성

커뮤니케이션

코드는 컴퓨터가 해석하고 실행한다. 하지만 코드를 수정하고 코드로 기능을 추가하는 것은 사람이 한다. 미래의 나 혹은 동료가 하게 된다. 그리고 항상 프로그래밍은 개발 비용보다 유지보수의 비용이 컸고 유지보수를 하기 위해서는 반드시 코드를 읽어야 한다.
하지만 코드를 읽기 어렵다면 코드와의 커뮤니케이션이 어렵고 이는 다른이의 유지보수 비용이 증가함을 뜻한다. 즉, 다른이가 읽을 수 있게 커뮤니케이션을 높이는 가치는 비용을 줄이는 가치를 가진다.

단순성

애플리케이션을 지속적으로 성장한다. 그리고 코드양은 늘고 복잡성은 올라간다. 복잡성이 올라가면 수정불가능한 코드가 될 수도 있어 프로그램이 위험해진다. 항상 단순하게 만들 수 있지 않을까를 고민해봐야한다. 단순한 코드가 커뮤니케이션을 항상 좋게 만들지는 않지만 어느정도 커뮤니케이션 증가에도 도움을 준다.

유연성

유연한 코드는 확장가능하게 하고 이는 새로운 기능 개발에 비용을 줄일 수 있게 된다. 하지만 유연성은 단숨함을 줄여 코드를 복잡하게 만들 수 있다. 그래서 눈 앞에 있는 유연성만 추구하고 예측에 의한 유연성은 지양해야 한다.

원칙

원칙은 항상 지켜야하는 것과 같은 것으로 생각된다. 원칙의 가치는 항상 지킴으로써 나온다. 항상 지켜지고 있는 원칙이 깨진다면 버그를 쉽게 발견할 수 있다. 그것도 코드 작성 수준에서 발견하는 버그이기에 디버깅 비용도 낮다. 이렇듯 원칙은 지킴으로써 얻어지는 가치다.

지역적 변화

최대한 스코프를 작게 가져가고 변화를 축소하는 것이다. 쉽게 말해 전역변수 쓰지말고 지역변수를 쓰라는 말이다. 지역적인 변화는 작은 변화이기에 작은 범위만 영향을 주게 되고 그에 따라 변경에 따른 비용이 작아진다.

최소 중복

DRY에 해당되는 내용이다. 같은 일을 하는 코드가 여러군데 있다면 변경사항이 있을 때 그 일을 하는 모든 곳을 고쳐야한다. 이는 사람이 하는 일이기에 반드시 버그를 발생시킨다. 중복은 발견되는 것이기 때문에 발견되는 즉시 줄여야한다.

대칭성

사람의 인지적 특성에 기인했다고 한다. add() 메소드가 있는 곳에 remove()가 있다. 이런식으로 항상 대칭적으로 표현해야 코드를 읽기 수월하다.

로직과 데이터 결합

A데이터를 다루는 로직은 A와 같은 곳에 있어야 한다. A를 다루는 로직이 B에 있다면 이를 이해하는 것은 어렵게 된다.

선언적 표현

C언어부터 프로그래밍은 명령형 프로그래밍이 주로 이루고 있다. 이는 프로그램의 흐름을 따라가면서 이해해야 한다. 이런 방식은 사람이 이해하기에는 이해하기 어려울 수 있다. 조건문이나 수행순서가 중요한 구문 말고 일반구문의 경우 선언적으로 표현한다면 코드를 이해하기 쉬워진다.

변화율

같은 변화를 갖는 것은 같은 변화가 있는 것끼리 묶는다. 변화율의 개념은 어떻게 코드를 구분할 것인가에 대한 원칙을 알려준다. 객체지향이 "코드를 어떻게 격리할 것인가"가 관심사 이듯이 변화율은 OOP에서 중요한 개념이다.

패턴

패턴은 어떤 결정을 하기 위한 하나의 정형화되고 반복된 행위를 뜻한다. 루프를 도는 목적은 다를 수 있자만 루프의 고려사항들은 정해져 있다. 읽기 쉽고, 검증하기 쉬우며, 효율적이어야 한다. 이러한 일련의 상황들을 고려하는 것이 패턴이다. 물론 우선순위가 다를 수 있다. 어떤 루프는 빨리 돌아야할 수 있다. 반대로 어떤 루프는 읽기 쉬워야할 수 있다. 이렇게 조금의 차이가 있음을 관찰하고 A패턴이 좋을지 B패턴이 좋을지를 선택하게 된다.

중요한 것

위 설명한 가치나 원칙 그리고 패턴을 알아야하는 이유는 비용을 줄이기 위함이다. 여기서 비용은 시간과 돈을 뜻한다. 커뮤니케이션이 잘 되는 단순하고 유연한 코드를 짜고, 회사나 팀에서 정한 원칙을 지켜 버그를 쉽게 발견할 수 있는 환경을 만들고, 정형화 된 결정사항들을 확인하고 패턴화하여 빠르게 적용한다면 비용감소를 이룰 수 있게 된다. 이는 회사에서 개발자로서 기여할 수 있는 큰 부분인 것 같다.
난 이제 "왜 그렇게 짰어?"의 대답을 할 수 있게 된 것 같다. "어떠한 가치를 가지고 원칙을 지켜 패턴화하여 이렇게 짠 것이 비용을 줄일 수 있기 때문에 이렇게 짰습니다." 라고 기준을 가지고 말할 수 있게 된 것 같다.

참고

• 켄트백의 구현패턴
• 코드스피츠