23-03-03 (금) 리펙토링 세미나

김민섭·2023년 3월 3일
0

세미나

목록 보기
1/2

세미나를 진행하면서 나왔던 내용들을 생각나는 대로 정리해 봅니다.

리펙토링의 정의

동작은 그대로 유지한 채로 내부 구조를 변경하는 것

여기서 중요한 점은 동작은 그대로 유지한 채로 라는 문구이다.
리펙토링 과정에서 코드가 깨지는 경우가 빈번한데 리펙토링 동안에는 괜찮겠지...? 라는 생각은 금물!
리펙토링은 언제나 정상적으로 동작이 될 수 있도록 유지한 채로 차근차근 바꿔나가는 것이다.

리펙토링과 최적화의 차이

리펙토링: 사람이 보기 편하도록 내부 구조를 변경하는 것
최적화: 소프트웨어의 속도를 빠르게 만드는 것

리펙토링은 컴퓨터 친화적이 아니라 사람이 보기 편하도록 내부 구조를 변경하는 것이기 때문에 단기적으로는 소프트웨어의 속도가 느려질 수 있으나
사람이 해당 코드를 이해하기 쉽도록 만들어 놓은 것이기 때문에 프로그램의 속도를 빠르게 만드는 최적화 단계에서 수월할 것

또한 리펙토링 기간으로 인해서 개발 속도가 느려보일 수 있으나 유지 보수 단계에서 큰 빛을 발휘할 것이다.

개발자는 두개의 모자를 써야 한다

  1. 기능 추가의 모자
  2. 리펙터링의 모자

한 종류의 모자를 썼으면 해당 모자의 역할에 집중하고 그 후에 다른 모자를 쓸 것!
기능을 추가하면서 리펙터링을 했으면 좋겠다고 느껴지는 부분이 있다면 짧은 주석으로 남겨놓은 후 일단은 넘어가는 것이 좋다.

리펙토링 팁

  1. 함수나 변수, 클래스 같은 것들을 네이밍 할 때에는 이름만 보고도 그것이 어떤 역활을 하는지 알 수 있도록 할 것
    => 깔끔하고 명확한 이름은 주석 없이도 해당 코드가 어떠한 역활을 하는지 알 수 있게 해준다
  2. 중복 코드는 추출하여 하나로 만들 것
    => 중복되는 코드는 코드의 가독성만 해칠 뿐이다
  3. 많은 수의 매개 변수가 필요하다면 객체로 만드는 등의 형식을 이용하여 해당 매개 변수가 어떤 역활을 하는지 명시할 것
  4. 매개 변수는 변수로 넣기
    => 숫자형이나 문자열로 넣는다면 해당 매개 변수가 어떠한 역활을 하는지 명확하게 알 수 없다
  5. 하나의 역활을 하는 코드를 여러군데에 흩뿌려 놓지 않기
  6. 다른 역활을 하는 코드들을 한곳에 몰아 넣지 않기
  7. 단일 책임 원칙은 확실하게
    => 문제가 생겼을 경우 수정을 용이하게 하기 위해서
  8. 나중에 필요할거야 라는 생각으로 현재 필요하지 않은 기능들을 추가하지 않기
    => 나중에 사용될지 확실하게 알 수 없는 데다가 당장 코드의 가독성만 해칠 뿐이다
profile
getting ready to run

0개의 댓글