C#의 using var 예제에 연산 하나를 더 넣어 생각해 봐요. using 선언은 자신이 속한 범위가 끝날 때 자원을 해제해요. 짧아진 문법만큼이나 그 범위가 중요해요.
어떤 메서드가 중첩된 using 블록에서 input을 얻고, Read(input)을 호출하고, 그 블록을 나온 뒤 Publish()를 호출한다고 해 봐요. 편집기가 이 블록을 메서드 범위의 using 선언으로 바꾸겠다고 제안해요. 그러면 Publish()가 해제보다 먼저 실행돼요. Publish()에서 예외가 나면 메서드를 빠져나가면서 그 연산 뒤에 해제가 이뤄져요. 원래 순서에서는 이미 해제가 끝난 상태였고요.
편집기가 예상한 문법을 정확히 찾았을 수는 있어요. 그렇다고 바뀐 자원 수명이 이 메서드에 적합하다는 근거까지 생기지는 않아요.
이 작은 예제에서 리팩터링을 받아들이는 사람이 범위 변경을 판단하려면, 미리보기에 무엇을 표시해야 할까요?
Publish()가 이제 해제 전에 실행된다는 점을 표시해 주세요. 편집기가 문법을 인식해도, 늘어난 자원 수명이 애플리케이션에 적합한지까지 확인한 건 아니에요.
표시된 Publish()는 input을 해제한 뒤에만 실행할 수 있다고 가정해 봐요. 그러면 겉보기에는 평범한 수정이어도, 메서드 범위로 옮기는 변경은 그 요구사항을 깨뜨려요.
이번에는 원래 안쪽 블록을 남기고 그 안에 선언을 넣어 봐요. 해제 경계는 여전히 그 블록의 끝이에요. 저는 이처럼 범위를 좁게 유지하는 수정도 별도 선택지로 제공하고, 영향을 받는 문장들을 미리보기에 보여 주겠어요. 핵심은 어느 범위를 유지할지인데, 지워진 중괄호만 보여 주면 그 판단에는 별 도움이 안 돼요.
그 표시는 Dispose가 언제 실행되는지 알려 줘야 해요. input을 쓰는 모든 쪽의 작업이 끝났다는 뜻으로 보여서는 안 되고요.
Read(input)이 input의 참조를 유지하는 콜백을 저장한다고 가정해 봐요. 원래 블록을 보존하더라도 그 콜백을 어떻게 쓸지는 따로 확인해야 해요. 리팩터링 판단은 해제 범위에 맞추고, 도구가 범위 밖으로 전달되는 콜백을 식별할 수 있다면 검토 대상으로 표시하겠어요. 참조에 계속 접근할 수 있다는 사실만으로 이미 해제한 자원을 사용해도 된다는 근거가 생기지는 않아요.
