최근에 RailsConf 2014에서 "All the Little Things" 를 보았습니다 .
def tick
if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert'
if @quality > 0
if @name != 'Sulfuras, Hand of Ragnaros'
@quality -= 1
end
end
else
...
end
...
end첫 번째 단계는 함수를 여러 개의 작은 함수로 나누는 것입니다.
def tick
case name
when 'Aged Brie'
return brie_tick
...
end
end
def brie_tick
@days_remaining -= 1
return if quality >= 50
@quality += 1
@quality += 1 if @days_remaining <= 0
end내가 흥미로 웠던 것은이 작은 함수들이 작성되는 방식이었습니다. brie_tick예를 들어, 원래 tick함수 의 관련 부분을 추출하여 작성된 것이 아니라 test_brie_*단위 테스트를 참조하여 처음부터 작성되었습니다 . 이러한 모든 단위 테스트가 통과되면 brie_tick완료된 것으로 간주됩니다. 모든 작은 기능이 완료되면 원래의 모 놀리 식 tick기능이 삭제되었습니다.
안타깝게도 발표자는이 접근 방식으로 인해 네 가지 *_tick기능 중 세 가지 기능이 잘못되었다는 사실을 알지 못했습니다 (다른 기능은 비어 있음). *_tick기능 의 동작 이 원래 tick기능 의 동작 과 다른 경우가 있습니다. 예를 들어, @days_remaining <= 0에 brie_tick있어야합니다 < 0- 그래서 brie_tick호출 할 때 제대로 작동하지 않습니다 days_remaining == 1와 quality < 50.
여기서 무엇이 잘못 되었습니까? 이러한 특별한 경우에 대한 테스트가 없었기 때문에 이것이 테스트 실패입니까? 또는 리팩토링 실패-코드를 처음부터 다시 작성하지 않고 단계별로 변환해야합니까?
2
질문이 확실하지 않습니다. 물론 코드를 다시 작성해도됩니다. " 코드 를 간단히 다시 작성해도 괜찮습니다"라는 말의 의미가 무엇인지 잘 모르겠습니다 . "많이 생각하지 않고 코드를 다시 작성해도 괜찮습니다."라고 묻는다면 그 방법으로 코드 를 작성 하는 것이 좋지 않은 것처럼 대답은 '아니오' 입니다.
—
John Wu
이는 주로 성공 사례를 테스트하는 데 주로 중점을 둔 테스트 계획과 오류 사례 또는 하위 사용 사례를 다루는 데 거의 또는 전혀 적용되지 않기 때문에 발생합니다. 따라서 주로 적용 범위가 누출됩니다. 테스트 누출.
—
Laiv
@JohnWu-리팩토링은 일반적으로 단순히 코드를 다시 작성하는 것이 아니라 소스 코드 ( "추출 방법"등)에 대한 일련의 작은 변환으로 수행된다는 인상을 받았습니다. 링크 된 프리젠 테이션에서 수행 된 기존 코드 확인).
—
user200783
@JohnWu-처음부터 다시 작성하는 것이 허용 가능한 리팩토링 기술입니까? 그렇지 않다면 리팩토링에 대한 잘 알려진 프레젠테이션이 그 접근 방식을 취하는 것이 실망 스럽습니다. 허용되는 경우 의도하지 않은 행동의 변화는 누락 된 테스트에서 비난받을 수 있습니다. 그러나 테스트가 모든 가능한 경우를 커버한다고 확신 할 수있는 방법이 있습니까?
—
user200783
@ User200783 더 큰 질문입니다. (테스트가 포괄적인지 어떻게 확인합니까?) 실용적으로 변경하기 전에 코드 적용 범위 보고서를 실행하고 그렇지 않은 코드 영역을 신중하게 검사합니다. 개발 팀이 논리를 다시 작성할 때이를 염두에두고 연습하십시오.
—
John Wu