'래팩토링'에 해당되는 글 1건

  1. 2008.09.02 [rwb] 리팩토링 워크샵 2장 도전하기

A. 단순한 디자인에 대한 켄트 백의 규칙들이 정당한 것인지 설명해 보자.

 - 모든 테스트를 실행할수 있어야 한다.
  테스트를 실행할수 있어야 한다가 맞다.
  각 단위, 기능 별로 나누거나, 모아 놓은 후 단위별로 테스트가 가능하다면
  오류를 최대한 줄일 수 있다고 생각함
  그러나 소규모 모듈을 만들면서 모두를 테스트 가능 하도록 프로그래밍 하기는 힘들다.
  시간적으로나 인력적으로나.
  --> 효율적인 테스트 방법을 익히고, 테스트가 용이하도록 코드를 작성하는 방법을 알수있을까?
 
- 중복된 로직이 없어야 한다.
   < 병렬 클래스 계층구조와 숨은 중복에 주의한다.>
  유사한 클래스, 유사한 메소드를 작성할 경우 copy&paste로 작성하게 되는 경우가 많고,
  메소드 명세에 대한 정의가 없이 작성해 내려갈 경우에 같은 로직을 작성하거나, 로직의 일정 부분을
  복사해서 사용하는 경우가 있다. 이런 경우 추후에 수정이나 추가를 하기가
  어렵거나 매우 번거롭게 된다.

  그러므로 중복된 로직은 당연히 없어야 하며.
  중복된 로직이 생길경우 리팩토링으로 제거한다.
 
- 프로그래머들에게 중요한 의도를 모두 알려줄수 있어야 한다.

  모두 알려 줄수 있어야 한다는 것에 동의.
  그러나, 방법은 주석이나 코드나 뭐든지 상관없다는 것인지..
  코드로만으로 중요한 의도를 모두 알려줄수 있어야 한다는것이라면 대략...
  나름대로 작성하고 있는 주석도 타인이 읽기가 너무 불편하고
  클래스나 메소드에 수정을 가할때 주석은 누락 시키는 경우가 너무 많다.


 - 클래스와 메소드는 가능한 적어야 한다.

  가능한 적어야 한다는 것에 전적으로 동의할수 밖에 없음.
  현재 너무 많아져서 관리,파악 하기가 너무 어렵다.  

대부분의 리팩토링은 이러한 태도를 (중간 크기의 리팩토링에서도 안전성이 우선되는) 나타낸다.
파울러의 카탈로그에서 제안하는 방법은 단순히 기존 코드를 잘라내서 이동하는 것이 아니라,
코드를 복사해서 기존 코드를 삭제하기 전에 조정하는 것이다.

B. 이 규칙들에는 왜 우선 순위가 있는가? 의사 소통이 중복 회피에 우선하는 예를
    찾을 수 있는가?
 1- 시스템의 완성도 면으로 가장 중요한 순서로 규칙들이 나열된것이 아닐런지.
    또는 리팩토링을 하는 순서대로 규칙들이 나열된것으로도 생각해볼수 있지 않을까.
    우선 순위가 높은 규칙대로 리팩토링을 시행하는 것도 좋을 듯하다.
   
 2-  개발 기간이 짧은 경우? 상속의 구조를 사용하지 않으려 하는 경우에는
    의사표시를 하고 중복된 로직을 남겨 놓을 수도 있지 않을까...
   (잘 모르겠다..)

 1-  (테스트 - 의사표시 - 중복 - 작은 코드)
    1) 사용할 것이라면 모든 테스트를 통과해야한다.
    2) 나중에 우리가 작성한 코드를 읽을 사람에 관한 우리의 직관에 호소한다.
    3) 중복된 코드를 문제를 야기한다. 중복은 한 쪽은 변경하고 다른 한쪽은 변경하지 않는 문제에
       매우 취약하다.
    4) 모든 상황과 조건이 동일하다면 더 작은 코드를 선호한다.

 2- 핵심을 코드를 읽은 사람의 이해력에 달렸음. 중복이 이해하는 데 도움이 된다면 중복을 묵인할수 있음.
     테스트 코드에서는 의사 소통을 위해 중복이 있는 경우가 간혹 존재하기는 함

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 영겁회귀

티스토리 툴바