상수도 풀어서 의미를 담아내자

8장 설명하는 변수에 이어서 상수 또한 같은 맥락에서 바라봤다고 느낍니다.

그런데 ONE = 1 이라는 예시가 실소를 자아냈습니다.

맥락적 의미가 없이 공통으로 사용하고 싶은 것을 만든 느낌이랄까요?

켄트 백은 이를 빈약한 의미라고 표현했습니다. 제목에 있는 설명한다는 것의 의미를 되뇌여 볼 필요가 있다고 생각합니다.

일정(一定)한 내용(內容)을 상대편(相對便)이 잘 알 수 있도록 풀어 밝힘. 또는 그 말.

magic number, 우발적 중복이라는 개념들이 생각납니다.

저도 의미없는 상수는 선호하지 않는 편입니다.
예전에는 리터럴을 보면 무조건 반사로 리터럴 상수로 만들곤 했었습니다. 그러다보니 의미없는 리터럴 상수 이름이 나온 적이 종종 있었습니다.(되돌아보면 문제가 되진 않았지만 굳이 시간을 들여서 할 작업이었나 싶습니다.) 지금은 그러지 않습니다. 맥락을 파악하고 그 맥락에 맞는 이름이 도출될 때 리터럴 상수로 만듭니다.

ONE = 1 이라는 예시를 보고 '내가 만약 그런 코드를 마주했다면' 을 가정하고 생각 해봤습니다.

1. 이 코드를 작성한 사람이 표현력이 부족하더라도 상수화를 통해 무엇인가를 표현하려 했다.
2. 미래의 독자를 염두에 두고 코드를 작성하려는 사람일 수 있겠다.
3. 애플리케이션 전반에 걸쳐 코드 스타일을 일관성 있게 유지하려 노력한다.
4. 용어는 모르더라도 '매직 넘버' 가 무엇인지 개념적으로 알고 있다.

물론 각각의 생각에 부정적인 꼬리가 달리기도 합니다.

1. 표현력이 부족하여 이 사람이 작성한 코드 문맥을 이해하는데 어려움이 있을 수 있겠다.
2. 오버 엔지니어링이 습관이 되어있을 수 있겠다.
3. 융통성이 없을 수 있겠다.
4. 경험은 있지만 이론적으로 정립이 되어있지 않아 작성한 코드마다 스타일이 다를 수 있겠다. (1번의 연장선)

다루고 있는 예시가 안티 패턴이라는 것은 부정하지 않지만, 마냥 부정적인 시그널로만 바라볼 것은 아닐수 있겠다는 생각을 했습니다.

상수들을 한곳에 모아두고...그리고 '경험적인' 소프트웨어 설계

다른 사람이 짠 코드를 보다 보면 시스템에서 사용하는 모든 상수를 하나의 파일 혹은 패키지에 정의해서 사용하는 것을 예전에는 자주 요즘은 간혹 봅니다.

이 코드 정리법에 뒤따르는 몇 가지 일들이 있습니다. 한번에 바뀌어야 하거나 함께 이해해야 하는 상수들을 한곳에 모아두고, 다른 이유로 묶인 변수들을 분리하는 후속 작업을 해야죠.

켄트 벡이 말하는 상수들을 한곳에 모으라는 말은 함께 쓰이는 예를 들면 클래스나 함수와 함께 모아두라고 느껴집니다.

그러한 일들은 차차 알게 될 것입니다. 결합도와 응집도는 뒤로 하고, 일단 작업하세요.

다시 C&C 가 등장하네요. C&C를 실천하기 위해서 일상에서 이런 소소한(?) 경험을 계속 쌓아가야 한다고 말하는 듯합니다.

이론이나 순수한 논리보다는 관찰이나 경험에 근거해서 충분한 관심을 갖고, 면밀히 검증합니다.

스스로 이름으로 설명해보자

스스로 설명하는 코드의 장점은 많은 분들이 이미 아실 것이라 생각합니다.
이름은 그 중 매우 중요한 요소이구요.
.

저도 이런 개념을 너무 좋아하는데요, 단순히 원시값이나 문자열 리터럴에 적당한 상수 이름을 짓는 것을 넘어 좀 더 확장해서 사용할 수 있을 것 같습니다.
.

한 가지 예시로 불변 객체 상수에게 적절한 이름은 지어주는 것입니다.
책에 나온 것 처럼 Integer.ZERO, Integer.ONE 같은 것들이죠.
그리고 더 복잡한 객체에도 적용 가능하다고 생각하구요.
.

또한 꼭 불변 객체에만 적용 가능한건 아니라고 생각합니다.
자신의 이름이 나타내는 상태의 값들을 변경할 수 없어 상태가 변경 되어도 그 이름과 어긋나지 않는다면, 가변 객체라고 하더라도 여전히 사용할 수 있을 것 같습니다.