테스트 효과성을 검증하기 위한 방법은 여러가지 방법이 있습니다! 크게 3가지로 나눠 볼 수 있는데요. TC기반 / 결함기반 / 커버리지 기반 요렇게 3개로 나눌 수 있습니다. 테스트 케이스 기반 테스트 케이스 실패율로 판단하기 ⇒ 결함을 검출한 테스트 케이스의 비율이 높으면 효과적인 테스트라고 판단 ⇒ 그럼 결함 검출한 테스트 케이스의 비율이 높으면, 비효율적인 테스트라고 판단하게된다. 근데 이미 SW품질이 높거나 예외 테스트케이스가 없어서 실패율이 낮을 수도 있고, 특정 테스트만 편중해서 실패율이 높게 나올 수도 있다.. 테스트 케이스 효율성으로 판단하기 ⇒하나의 결함을 검출하기 위해 사용된 TC개수로 판단 ⇒ 하나의 결함을 검출하는데, 많은 수의 TC가 사용되면 효율이 낮은 것. ⇒ 왜냐하면 여러 테..
변수를 추출하는 것은, 리팩터링의 목적 중 하나인 코드의 가독성을 높이는 역할을 한다. 우테코 미션에서도 리뷰어 님들이 중간에 알아보기 힘든 코드가 있으면, 변수로 추출하라고 리뷰를 남겨주시기도 한다. 그런데 인라인으로 두어도 되는 코드를 일부러 변수에 할당하여 가독성을 높이라고 하셨던 리뷰어님도 계셨는데, 이 원칙을 지키다 보니, 모든 코드를 가독성을 주기위해서 변수에 할당하고 있었다. 어떤 미션에는 비동기 로직을 작성하는 코드가 필요했는데, 간단히, get,post,delete,put에 대해서 fetch를 하는 함수였다. response라는 객체로 무조건 응답값을 받아서 반환하고 있었는데, 이런 경우는 오히려 인라인으로 작성하라는 리뷰를 받았었다. 왜냐하면, "수정될 일이 적고", "누구나 이해할 수..
표현식이 너무 복잡해서 이해하기 어려울 때가 있다. 이럴 때 지역 변수를 활용하면 표현식을 쪼개 관리하기 더 쉽게 만들 수 있다. 그러면 복잡한 로직을 구성하는 단계마다 이름을 붙일 수 있어서 코드의 목적을 훨씬 더 명확하게 드러낼 수 있다. 이 과정에서 추가한 변수는 디버깅에도 도움된다. 디버거에 중단점을 지정하거나 상태를 출력하는 문장을 추가할 수 있기 때문이다. 변수 추출을 고려한다고 함은 표현식에 이름을 붙이고 싶다는 뜻이다. 이름을 붙이기로 했다면 그 이름이 들어갈 문맥도 살펴야 한다. 현재 함수 안에서만 의미가 있다면 변수로 추출하는 것이 좋다. 그러나 함수를 벗어난 넓은 문맥에서까지 의미가 된다면, 그 넓은 범위에서 통용되는 이름을 생각해야 한다. 다시 말해서 변수가 아닌 함수로 추출해야한다..
함수 인라인하기는 함수 추출하기의 정반대의 기법이다. 분명히 함수 인라인하기를 읽을 때에는, 내 코드를 슈도코드 급으로 가독성이 있게 만들겠다라는 생각이 들었는데, 오히려 그 함수를 인라인함으로써 가독성이 떨어질 수 있고 코드가 더러워질 수 있다는 생각을 들으니, 어디까지가 적절한 수준인가에 대한 의문이 들었다. 뭐가 읽기좋고 나쁘고는 결국엔 개인의 주관이 많이 개입할 것 같은데, 흠.. 이 부분은 의식하고 있다가 나에게 같은 경우가 생긴다면, 고려를 해봐야하나? 굳이 정하자면 제 3자가 읽기에 불편하지 않는 선에서는 인라인을 유지해도 괜찮을 것이라는 생각을 했다. 일단 확실하게 인라인하면 안되는 경우를 먼저 짚어보자. => 인라인하려는 함수가 다형 메서드일때, 서브클래스에서 오버라이드를 안해버리면 정상..
리팩터링 책은 목적이 분명히 드러나는 이름의 짤막한 함수를 이용하기를 권한다. 그래야 코드가 명료해지고 이해하기 시워지기 때문이다. 하지만 때로는 함수 본문이 이름만큼 명확한 경우도 있다. 또는 함수 본문 코드를 이름만큼 깔끔하게 리팩터링할 때도 있다. 이럴 때는 그 함수를 제거한다. 간접 호출은 유용할 수도 있지만 쓸데없는 간접 호출은 거슬릴 뿐이다. 간접 호출을 너무 과하게 쓰는 코드도 흔한 인라인 대상이다. 가령 다른 함수로 단순히 위임하기만 하는 함수들이 너무 많아서 위임 관계가 복잡하게 얽혀 있으면 인라인해버린다. 그중 간접 호출을 유지하는 편이 나은 경우도 있겠지만, 모두 그렇지는 않을 것이다. 함수 인라인하기를 활용하면 유용한 것만 남기고 나머지는 제거할 수 있다. 절차는 다음과 같다. 1...
리팩터링 기법에서 처음 소개되는 기법은 함수 추출하기이다. 한 마디로 어떤 코드 블록을 찾아서, 독립적인 함수로 추출하고 적절한 이름을 붙여주는 것이다. 그럼 언제해야하나? 1. 길이를 기준으로 삼을 수도 있고, 2. 재사용성을 기준으로 할 수도 있다. (2번이상 사용될 코드는 함수로 만드는 등) 3. 하지만 저자가 추천하는 방법은, "목적과 구현을 분리" 하는 것이 가장 합리적이라고 말한다. 코드를 보고, 무슨일을 하는지에 대해 한참이 걸린다면, 그 부분을 함수로 추출한 뒤에, 무슨일에 대한 걸맞는 이름을 짓는 것이다. 이렇게하면, 나중에 코드를 다시 읽을 때, 함수의 목적이 눈에 확 들어오고, 본문 코드에 대해서는 더 이상 신경 쓸일이 거의 없어진다. 즉, 슈도코드만큼 코드가 무슨일을 하는지 읽힐정도..
함수 추출하기는 마틴 파울러가 가장 많이 사용하는 리팩터링 중 하나이다. 코드 조각을 찾아 무슨일을 하는지 파악한 다음, 독립된 함수로 추출하고, 목적에 맞는 이름을 붙인다. 코드를 언제 독립된 함수로 묶어야 할지에 관한 의견은 수없이 많다. 먼저, 길이를 기준으로 삼을 수 있다. 가령 함수 하나가 한 화면을 넘어가면 안 된다는 규칙을 떠올릴 수 있다. 재사용성을 기준으로 할 수도 있다. 두번이상 사용될 코드는 함수로 만들고, 한 번만 쓰이는 코드는 인라인 상태로 놔두는 것이다. 하지만 저자는 "목적과 구현을 분리"하는 방식이 가장 합리적인 기준이라고 한다. 코드를 보고 무슨일을 하는지 파악하는데 한참이 걸린다면, 그 부분을 함수로 추출한 뒤, 무슨 일에 걸맞는 이름을 짓는다 이렇게 해두면 나중에 코드를..
- 리팩터링 2판 중 리팩터링은 분명 가치 있는 도구지만, 그것만으로는 부족하다. 리팩터링을 제대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 suite가 뒷받침해야한다. 좋은 테스트를 작성하는 일은 개발 효율을 높여준다. 테스트 작성에 시간을 뺴앗기는데 효율이 높아진다니? 직관에 어긋나는 효과라서 다른 프로그래머들 처럼 처음 깨달았을 때는 상당히 놀랬다. 그럼 효율이 좋아지는 이유를 함께 살펴보자. 프로그래머들이 어떻게 일하는지 가만히 살펴보면, 실제로 코드를 작성하는 시간의 비중은 그리 크지 않음을 발견할 수 있다. 현재 상황을 파악하기도 하고, 실게를 고민하기도 한다. 물론 대부분의 시간은 디버깅에 쓴다. 여러분도 디버깅하느라 밤늦게까지 고생한 경험이 있을 것이다. 프로그래머라면 누구..
