발견하지 못한 버그를 수정하는 것은 리팩터링인가?

원문 : IsFixingAnUnknownBugRefactoring     refactoring     3 September 2004

RefactoringBoundary.

Przemyslaw Pokrywka가 매우 난해한 질문을 했다. 에서 소개한 리팩터링 중에 하나로 Introduce Null Object라는 것이 있는데, (이것은 매우 유용한 리팩터링으로 Josh의 새 책에서도 다루고 있다) Przemyslaw의 요지는 이 리팩터링이 행동을 바꿀 수 있다는 것이었다. 만약 여러분이 null을 반환하는 메소드를 가지고 있고, 그 반환 값인 null에게 메소드 호출을 하면 null pointer exception을 받게 될 것이다. 이럴 때 Null Object를 사용해서 (예외를 발생시키는 것이 아니라) 기본 행동을 수행하도록 정의할 수 있다.

요즘 다수의 리팩터링들이 행동을 바꾸고 있는데, 이들은 근본적으로 그렇게 하도록 의도된 것 들이다. 예를 들어 Form Template Method를 적용하면, 프로그램이 다르게 동작한다. 핵심적으로 질문해야 할 것은 리팩터링 정의에서 언급한 “주목할 만한” 행동에 해당하는가 이다. “주목할 만한” 행동이란 프로그램이 원래 의도했던 것을 변경했는지 여부를 뜻한다. Introduce Null Object를 사용하면 프로그램에서 반환된 레퍼런스 변수를 조작하는 부분 (특히 null인지 확인하는 부분)을 살펴보아야 한다. 그렇기 때문에 이 리팩터링이 다소 복잡한 것이다.

질문 중에서 가장 흥미로운 부분은 만약에 버그가 있는 부분을 놓치면 어떤 일이 발생하는가 이다. 프로그램 내부의 어디에선가 null 레퍼런스에게 메소드를 호출하는 부분이 있다고 하자. 이 부분을 간과하여 놓쳤고 최종 사용자에게까지 전달되었다면, 리팩터링 전에는 예외를 발생시켰을 것이다. 리팩터링 후에는 기본 행동을 가지게 되고 이것은 사실상 버그를 고친 것에 해당한다. 미처 발견하지 못했던 버그를 고치는 것은 리팩터링일까?

그렇다. 왜냐면 스스로가 지각하지 못했거나 충분히 살펴보지 못한 (버그를 발생시키는) 행동은 “눈에 띄는” 행동이라고 할 수 없기 때문이다. 비록 버그를 알고 있었다 하더라도, 행동을 변함없이 유지하려고 인식했던 버그가 아니라면, 여전히 그것을 리팩터링이라고 불러도 좋다.

이것은 흥미로운 경우이기 때문에, 내 생각을 쉽게 바꿀 수도 있고 이와 비슷한 경계 사례들을 더 조사해 봐야겠다.

여기서 생각해 볼 것 한 가지는 수작업으로 하는 리팩터링과 툴 기반의 리택퍼링의 차이점이다. 손수 하는 리팩터링은 이런 식의 스스로 판단을 할 수 있는 반면에, 툴을 사용할 때는 좀 더 주의해야 한다. 아직은 툴들이 행동을 유지하는 것을 항상 보장하지는 못한다. 심지어, 파일로부터 읽어 들인 이름으로 리플렉션을 사용하여 메소드를 호출하는 경우 rename method는 리팩터링 도중 깨질 수 도 있다.

성능 최적화가 리팩터링인가?

RefactoringBoundary.

프로그램의 성능을 향상 시키기 위해서 변경을 가했을 때, 이것을 리팩터링으로 볼 수 있나요?

성능 최적화와 리팩터링은 둘 모두 프로그램에 같은 변경을 가하기도 하며, 특정한 변경은 둘 모두에 해당하기도 하지만, 이 둘을 별개의 것으로 구분한다.

이 둘을 구분하는 이유는 서로 다른 목적을 가지고 있기 때문이다. 리팩터링을 하는 목적은 코드를 좀 더 쉽게 이해하기 위한 것이며, 성능 최적화의 목적은 좀 더 빠르게 동작하도록 하는 것이다. (예를 들어) 변수 하나를 추가하는 것이 둘 모두를 위한 것이 될 수도 있겠지만, 그 작업을 어떻게 수행하느냐에 따라 본질적으로 둘 중 하나에 해당하게 된다. 리팩터링을 할 때는 코드를 깔끔하게 정리하는 것에 집중해야 한다. 이때, 변경을 성공적으로 수행했는지에 대한 판단은 프로그램을 더 쉽게 이해하도록 변경했는가에 대한 자신의 (주관적인) 평가에 기반하게 된다. 성능 최적화를 할 때는 성능에 집중해야 한다. 프로파일러를 이용하여, 변경을 가하기 전과 후의 성능을 비교함으로써 변경 작업이 진짜로 성능 향상에 도움이 되었는지 확인해야 한다. 만약 성능이 매우 중요한 상황이라면, 차후에 (컴파일러, VM 같은)환경이 변경 됐을 때 그것의 효율성을 다시 테스트 할 수 있도록 변경 사항을 로그로 남겨두어야 한다.

결론적으로 리팩터링과 성능 최적화는 서로 비슷하기도 하고, 다수의 변경을 공유하기도 하지만, 그들의 목적이 다르기 때문에 별개의 것으로 구분한다.

원문 : IsOptimizationRefactoring

Introduction to Apache Maven 2

원문 : http://www-128.ibm.com/developerworks/edu/j-dw-java-mavenv2.html
번역 : http://www.ibm.com/developerworks/kr/library/tutorial/j-dw-java-mavenv2.html
후기 :
잘 모르던 것(Maven 2)에 대한 글을 번역하는 일이 얼마나 난해한가를 경험할 수 있었습니다.
먼저 Maven에서 사용하는 용어들을 한글로 어떻게 옮겨야 할지 정말 난감했습니다. 그 중 가장 난감했던 것은 ‘Maven Coordinate’ 입니다. 처음에는 “Maven 위치” 그 다음 원문을 조금 읽다가 “Maven 좌표”로 수정하고 다시 또 읽다가 “Maven 이름”으로 바꿨지만 여전히 맘에 안들어서 그냥 “Maven 코디네이트”로 수정할까 생각중입니다.
또 난감했던 것으로는 주로 Artifact(이것도 사실 옮기기 난감했지만 그냥 ‘이건 옮기지 말자’라고 마음 먹고 고유명사처럼 사용하니까 맘이 편하더군요.)를 나타낼 때 원문에서 자주 depedency라고 하는데 이걸 그냥 ‘종속성’으로 하면 전혀 문맥이 이어지지가 않습니다. 그래서 ‘종속성을 가지는 것’ 이라고 풀어서 썼는데 참 난해하기 ‘서울역에 그지 없습니다.'(애욕전선 이상없다. 에서 나오는 대사 중 일부…)
번역 도중 그림과 소스코드가 자주 나오면 그보다 더 반가운 일은 없습니다. 완전 집중 했을 때 평균 1시간에 pdf로 3페이지 정도를 번역할 수 있었습니다. 하지만 글자가 많은 경우 1시간에 1페이지를 간신히 하기도 하고 그림과 코드가 많을 땐 1시간에 다섯 페이지를 번역할 수도 있었습니다.
빨리 하려다 보니 좋은 어구가 떠오르지 않으면 그냥 대강 글로 옮기고 넘어가는 부분이 많아져서 다 하긴 했지만 찝찝한 기분을 떨칠수가 없습니다. 이대로 보내드리는 건 ‘사실 번역 하기 싫다.’ 라고 말하는 거나 다름없기 때문에 좀 더 다듬어서 보내드려야겠습니다.

Pros and Cons of language oriented programming

Language Workbenches 번역 중에 일부분입니다. 현재 제대로 된 번역은 영회 형 블러그에 연재 중입니다. 🙂

먼저 해석 및 번역이 어려웠던 문장들 부터 정리해 봅니다.

However you’ll probably come acrossthe embedded term if you look around at more writing on DSLs.

기선 : ???
영회 :
하지만, DSL에 관련된 많은 글에서 포함된 DSL가 같은 표현을 자주 보게 될 것이다.

Parser generator and compiler compiler tools existthat can help you manipulate quite complex languages, andof course the whole point of DSLs is that they are usually quite simple.

기선 : 파서 생성기와 컴파일러 도구는 매우 복잡한 언어에서 작업할 때 도움이 된다. 그리고 물론 DSL의 주요한 점은 매우 간단하다는 것이다.
영회 :
파서 생성기와 컴파일러 저작 도구는 매우 복잡한 언어를 DSL다룰 때 도움을 준다. 게다가 DSL은 대개매우 간단하다.

This lack of integration hitsus in lots of ways with tooling.

기선 : 통합의 결여는 툴을 사용하도록 한다.
영회 :
통합의 결여로 인해 도구가 필요해진다.

We also have the full power of our base languageavailable to us at all times, together with all thetooling that exists in our base language.

기선 : 또한 항상 기반 언어에서 사용가능 한 특성들을 모두 사용할 수 있어야 한다.
영회 :
해당 언어에서 사용 가능한 모든 특성들을 활용할 수 있다.

While much of this machinery is missing from Cbased languages, we’re seeing features that can supportsome of this thinking.

기선 :  C 기반의 언어들은 이러한 기능이 빠져있는 반면, 이러한기능을 지원할 수 있는 특성을 찾는다.
영회 :
C에 기반하고 있는 언어들은 내부 DSL 작성에 적합한기능이 많이 빠져 있지만, 존재하지 않는 것은 아니다.

Ideally you want only the actual tools you need foryour job – certainly no less, but only a few more.

기선 : 이상적으로 사용자가 실제로 작업에 필요로 하는 툴만을 원할 것이다.
영회 :
이상적인 것은 어떤 작업을 수행하는데 꼭 필요한 기능만 제공하는 즉, 부족하지 않으면서 너무 많은 것을 제공하지는 않는 개발도구이다.


아직 끝까지 차이를 정리한 것이 아니라 다음에 추가로 수정을 해야겠습니다.

그리고 아래는 영회형이 지적 해 주신 수정사항입니다.

1. one of ~ 를 ~ 중에 하나로 번역하면.. 매우 어색하다.
2. COBOL inference – that mosttechnologies that are supposed to eliminate professional programmersdo nothing of the sort.
이 부분은 완전히 반대로 해석했다.

mosttechnologies that are supposed to eliminate professional programmers/ do nothing of the sort.
앞 부분 전체가 주어부인.. 상당히 복잡한 구문이지.

This reminds us of what I call the COBOLinference – that most technologies that are supposed to eliminateprofessional programmers do nothing of the sort.

기선 : COBOL inference란 대부분의 기술들이 전문적인 프로그래머들이아무것도 할 일이 없도록 발전한다는 것이다.
영회 :
이는 내가 코볼 추론(COBOL inference)이라고말하는 것을 떠올리게 한다. 대부분의 기술의 등장으로 전문적인 프로그래머가 사라질 것이라는 소문이 나돌지만그런 일은 벌어지지 않는다.

3. gettingdirect user input into programs
사용자를 참여시키는 것이 아니라 사용자의 입력을 프로그램에 넣는 것이지.



ps …

기선 :
영회 형:

이렇게 하다보니 어색해서..

기선 :
영회 :

이렇게 했습니다. ^^;;