변수의 선언과 초기화와 활용하는 시점을 가깝게 둬보자.

자바와 파이썬을 오가며 하던 행동들이 떠오르는 말을 만납니다.

변수를 사용하기 직전에 선언하고 초기화하는 경우
와 함수 맨 위에 모든 변수를 함께 선언하고 이후에 초기화하는 경우 중에서 어느 쪽이 코드를 읽고 이해하기 쉬울까요? - p.52

자바에 익숙하다보니 변수들이 블록의 상단에 가지런히 선언되고 초기화되는 것이 익숙합니다.

그리고 대강 이런 변수들을 활용하겠구나 예상하며 코드를 읽어가는 습성이 베인듯 합니다.

그러다 파이썬을 사용할 때는 문득문득 튀어나오는 변수들로 인해 예측가능성이 떨어지는 느낌을 받아 어색하게 느껴지는 경우가 있습니다.

그래서 간혹 파이썬에서도 블록의 상단에 변수들을 선언해두기도 합니다.

어느 쪽이 읽기 편할까요?

저는 블록 상단에 변수들을 선언해두는 스타일이 편합니다.

켄트 백은 변수의 선언과 초기화와 활용하는 시점을 가깝게 두라고 말하는데 앞으로 이부분을 의식하며 읽어봐야겠습니다.

그리고 TDD에서 말하는 안전하게 느끼는 작은 변경을 해나가라는 맥락과 같은 문장을 만나 일관성이 느껴집니다.

두려움을 느끼지 않는 수준의 바로 그 단계가 가장 좋은 수준입니다. - p.52

선언과 초기화 및 사용은 라이프사이클에 맞추어

지난 온라인모임때 나온 이야기인데, 그 때는 객체에 대해서 말했으나 보다 넓은 개념들로도 이야기해봅니다.

저는 변수, 엔티티뿐만 아니라 인터페이스도 라이프사이클 순서를 따르는 편입니다.

저는 평범한 뇌를 가지고 있어서 선형적, 순치적으로 생각하는게 익숙합니다.
그래서 항상 시간의 흐름으로 바라보는게 이해가 쉽고 저에게 직관적이죠.

지난번 말씀드린 엔티티를 예로 들면 다음이 구성됩니다.

1. 선언
2. 생성
3. 객체가 가지는 메소드들도 객체가 처리하는 시간순에 따라

public class Entity {
    // 1. 선언
    private final String id;
    private final Status status; 

<br/>

    // 2. 생성
    public Entity() {
    }

<br/>

    // 3. 메서드들
    public void init() 
    public void use1()
    public void use2()
    public void end()
}

객체 뿐만 아니라, 어떤 흐름을 갖는 usecase 인터페이스도 마찬가지입니다.

1. 해당하는 유즈케이스의 시작
2. 유즈케이스의 중간
3. 유즈케이스의 끝

pubic interface XXUseCase {
    public void use1()
    public void use2()
    public void destroy()
}

이렇게 하면 위에서 아래로 신문기사 읽듯이 읽으면서, 객체나 유즈케이스의 라이프사이클을 자연스럽게 인지할 수 있습니다. 또한 구현부도 보면 항상은 아니지만 대부분의 경우에, 같은 변수를 조작합니다.

이러한 구성은 저의 인지적 부하를 낮추어서 저는 라이프사이클에 따른 선언을 선호하는 편입니다 :)

소스 코드는 곧 설계다

7장 마지막 문장 '설계'라는 낱말에 계속 눈이 갑니다.

커다란 설계 변경은 어렵고 무섭죠? 더 작은 단계로 진행하세요. 그래서 무섭다면, 더 작게 하세요. 두려움을 느끼지 않는 수준의 바로 그 단계가 가장 좋은 수준입니다.

켄트 벡은 책 '서문'과 '들어가며'에서 '설계'에 대해 계속 언급했습니다.

제 목표는 독자들이 아침에 책을 읽고 오후에는 더 나은 설계를 할 수 있도록 하는 것입니다.

그리고 1장 부터 15장 까지 코드 정리법을 소개합니다.
책 구매 리뷰를 보니 매우 간결하게 쓰여진 코드 정리법을 보면서 어떤 분들은 이것이 설계와 어떤 관계인지 의구심이 들었을 수도 있겠다는 생각이 들었습니다.

그러다가 우연히 로버트 마틴의 책 <클린 소프트웨어> 부록을 보다가 잭 리브스가 1992년에 <C++ 저널>에 기고한 '소프트웨어 설계란 무엇인가?' 글을 읽었습니다.
번역본은 이곳에서 보실 수 있습니다.

요는 코딩, 테스트, 디버깅도 설계의 일부로 보아야 한다는 것이었습니다.

스프링 프레임워크를 만든 로드 존슨이 쓴 'Developers, Developers, Developers' 글도 같은 맥락이라고 생각합니다.

좋은 설계란 무엇일까요? 로버트 마틴은 <클린 아키텍처>에서 아래와 같이 말하고 있습니다.

설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 다름없다. 이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋을 설계라고 말할 수 있다. 새로운 기능을 출시할 때 마다 비용이 증가한다면 나쁜 설계다. 좋은 설계란 이처럼 단순명료하다.

새로운 기능을 출시할 때 마다 비용이 증가하는 것을 막는 핵심에 작고, 점진적인 코드 정리가 있다고 생각합니다.

---

<클린 아키텍처>에서 코드 정리를 언급하고 있는게 재미 있어 공유합니다.

이들 개발자는 "코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!"라는 흔해 빠진 거짓말에 속는다. 이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다. '시장 출시가 먼저'라는 생각을 하는 이유가 바로 뒤에 여러 무리의 경쟁자가 뒤쫓고 있고, 경쟁자보다 앞서 가려면 가능한 빠르게 달려야 하기 때문이다.

비문법적인 부분에서의 scope

이런 내용은 비문법적인 scope라고 생각합니다.

Java의 변수 scope에서 가장 보편적이고 인상 깊은 곳은 for의 int i로 대표 되는 인덱스 변수라고 생각합니다. 이 변수를 for scope에 격리시키는 이유야 말로 scope이 왜 필요한지 보여주는 것 같습니다.

우리는 i를 필요할 때 잘 쓰고, 그 필요가 끝나면 i에 대해서 안전하게 잊어 버릴 수 있습니다. 지속적으로 인지 부하를 낮춰갈 수 있게 해줍니다.

변수의 선언과 초기화 부분을 정리하는 것도 이와 같은 맥락이라고 생각합니다. 문법적으로 안전하게 지켜주는 것은 없지만, 우리가 필요할 때 필요한 것들만 살펴보게 해줍니다.
(+로 final 까지 쓰면 변경에서도 안전해집니다.)

이 글을 쓰며 반대 경우도 생각해봤습니다. 모으면 무엇이 좋을까?
클래스의 멤버 변수가 하나의 예시가 될 것 같습니다. 변수들을 보면 이 클래스가 뭘 하는지, 알려줄 수 있는지가 보일 것 같습니다.

하지만 함수 내에서는 무엇을 해줄지가 이미 이름으로 드러납니다. 그래서 득보단 실이 큰 것 같습니다.