VBA Rubberducking (Part 4)

VBA Rubberducking (Part 4)

이 글은 Rubberduck Blog의 VBA Rubberducking (Part 4) 글을 번역하며 공부하기 위한 기록으로, 일부 생략된 부분이 있을 수 있습니다. 오역, 오타에 관한 자유로운 의견 감사드립니다.

---

이 포스팅은 오픈소스 VBE 애드인 Rubberduck의 다양한 기능을 안내하는 시리즈 중 네 번째 게시물입니다.

첫 번째 게시물은 탐색 기능에 관한 것이었습니다.

두 번째 게시물은 코드 검사기의 내용입니다.

세 번째 게시물은 단위 테스트의 내용입니다.

리팩터링 (Refactorings)

우리는 처음에 코드를 검사할 수만 있어도 행복했습니다.

곧 "검사 신속-수정"이 다른 것일 수도 있다는 것을 깨닫습니다.

검사 신속 수정 중 몇개는 본격적인(full-fledged) 자동 리팩터링 작업이라는 것이지요. 식별자의 이름 변경과 올바른 수행하는 것은 Ctrl+H/식별자 바꾸기와는 매우 다릅니다. 기존의 메서드에서 불필요한 파라미터를 수동을 제거하는 것은 모든 호출문(Call sites)을 손상시키며 코드가 더 이상 컴파일되지 않습니다. Rubberduck은 모든 호출문를 주시하고 있으며, 코드 컴파일을 위해 어떤 인수를 제거해야 하는지 알고 있습니다.. 또한 손으로 하는 것보다 훨씬 빠릅니다!

Rubberduck 1.3은 이름 바꾸기(Rename)과 메소드 추출 리팩터링(Extract Method refactorings)이 적용되었습니다; v1.4.3에서는 파라미터 제거(Remove Parameters)와 리오더 파라미터 리팩터링(Reorder Parameters refactorings)이 적용되었습니다.

Rubberduck 2.0은 몇 개 더 소개합니다.

상황에 맞는 메뉴 명령이 활성화 됩니다: 파서 상태(parser state)나, 현재 선택된 항목이 될 수 있습니다.

Rename (이름 바꾸기)

꽤 잘 알려진 리팩터링입니다. 거의 대부분의 식별자 이름을 바꾸는 나머지 코드 기반에 영향을 미칩니다.

Extract Method (메소드 추출)

거의 완전히 재작성된, v2.0 Extract Method 리팩터링은 상당히 견고해지고 있습니다.

Make a valid selection, and take that selection into its own member, replacing it with a call to the extracted code, all parameters and locals figured out for you.

Extract Interface (인터페이스 추출)

VBA는 상속 인터페이스(interface inheritance)를 지원합니다; Rubberduck은 모듈의 모든 public 멤버를 기존 모듈이 구현(Implements) 하는 클래스로 쉽게 가져올 수 있습니다. 추상화에 대한 VBA만의 코딩 방법입니다. 단위 테스트는 구체적인 구현보다, 추상화에 의존한 코드 테스트를 좋아하는데, 그러면 테스트가 메시지 상자 표시, 파일이나 데이터베이스 쓰기같은 원치 않는 부작용을 유발하지 않고 가짜 의존성을 제공("주입")하는 테스트를 제공할 수 있습니다.

Implement Interface (상속 인터페이스)

인터페이스의 모든 멤버를 구현하는 것(그리고 인터페이스의 모든 멤버는 구현되어야 합니다)을 지루할 수 있습니다; Rubberduck은 Implements 문에 지정된 인터페이스의 모든 멤버에 대해 자동으로 stub method를 만들어줍니다.

Remove/Reorder Parameters (파라미터 제거/리오더)

Reworking a member’s signature is always annoying, because then you have to cycle through every single call site and update the argument list; Rubberduck knows where every call site is, and updates all call sites for you.

Move Closer to Usage (사용장소에 더 가까이)

변수는 가능한 작은 범위를 가져야 합니다. "scope too wide" 혹은 "Move ~ variable 'myVariable' to a smaller scope.' 검사는 이 리팩터링을 사용하여 선언(Dim As ~)을 처음 사용하는 곳 바로 위로 이동시킵니다; 또한 관리하기 좋게 조각으로 자르려는 거대한 메소드의 맨 위에 "선언의 벽(walls of declarations)"을 재배치할 수 있습니다. (it also works to rearrange “walls of declarations” at the top of a huge method you’re trying to cut into more manageable pieces.)

Encapsulate Field (필드 캡슐화)

필드는 내부 데이터이고, 구현 세부 정보입니다; 객체는 public 필드는 노출하지 않아야 하며, 캡슐화하여 속성으로 노축해야 합니다. Rubberduck은 새 필드의 이름을 지을 만큼의 노력으로 필드를 새로운 속성을 만들어줍니다. (Rubberduck turns a field into a property with only as much effort as it takes to name the new property.)

Introduce Parameter/Field (파라미터/필드 소개)

Pretty much the antagonist of move closer to usage, this refactoring promotes a local variable to a parameter or a field, or a parameter to a field; if a new parameter is created, call sites will be updated with a “TODO” bogus argument that leaves the code uncompilable until an argument is supplied for the new parameter at all call sites.

이어지는글

VBA에서의 OOP: 불변성 & 팩토리 패턴 (작성중...)

VBA / INDEX