[리팩터링] 챕터02. 리팩터링 원칙

 

😀 책에서 기억하고 싶은 내용을 써보세요.

• 리팩터링 [명사] (79p)
  => 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
  
  
• 리팩터링(하다) [동사] (79p)
  => 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 래팩터링 기법을 적용해서 소프트웨어를 재구성하다.
  
  
• 리팩터링은 결국 동작을 보존하는 작은 단계들을 거쳐 코드를 수정하고,
  이러한 단계들을 순차적으로 연결하여 큰 변화를 만들어내는 일이다. (80p)
  • 따라서 래픽터링하는 동안에는 코드가 항상 정상 작동하기 때문에 전체 작업이 끝나지 않았더라도 언제든 멈출 수 있다.
    
    
• 리팩터링은 성능 최적화와 비슷하다. (80p)
  • 둘 다 코드를 변경하지만 프로그램의 전반적인 기능은 그대로 유지한다.
    단지 목적이 다를 뿐이다. 리팩터링은 성능이 좋아질 수도, 나빠질 수도 있다.
• 나는 소프트웨어를 개발할 때 목적이 ‘기능 추가’냐, 아니면 ‘리팩터링’이냐를 명확히 구분해 작업한다. (81p)
  • 기능을 추가할 때는 ‘기능 추가’ 모자를 쓴 다음 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다.
    진척도는 테스트를 추가해서 통과하는지 확인하는 방식으로 측정한다.
    
    
• 반면 리팩터링 할 때는 ‘리팩터링’ 모자를 쓴 다음 기능 추가는 절대 하지 않기로 다짐한 뒤 오로지 코드 재구성에만 전념한다. (81p)
  • 테스트도 새로 만들지 않는다.
  • 부득이 인터페이스를 변경해야 할 때만 기존 테스트를 수정한다.
    
    
• 같은일을 하더라도 설계가 나쁘면 코드가 길어지기 십상이다. (82p)
  • 사실상 같은 일을 하는 코드가 여러 곳에 나타날 수 있기 때문이다. 그래서 중복 코드 제거는 설계 개선 작업의 중요한 한 축을 차지한다.
  • 코드가 길수록 실수 없이 수정하기 어려워진다.
  • 이해해야 할 코드량도 늘어난다.
• 프로그래밍은 여러 면에서 마치 컴퓨터와 대화하는 것과 같다. (82p)
• 프로그래밍은 결국 내가 원하는 바를 정확히 표현하는 일이다. (82p)
• 문제는 프로그램을 동작시키는 데만 신경 쓰다 보면 나중에 그 코드를 다룰 개발자를 배려하지 못한다는 데 있다. (82p)
• 코드가 명확하면 버그를 만들 가능성도 줄고, 버그를 만들더라도 디버깅하기 훨씬 쉽다. (84p)
• 나는 코드를 파악할 때마다 그 코드의 의도가 더 명확하게 드러나도록 리팩터링할 여지는 없는지 찾아본다. (86p)
  • 조건부 로직의 구조가 이상하지 않은지 살펴보기도 하고, 함수 이름을 잘못 정해서 실제로 하는 일을 파악하는 데
    시간이 오래 걸리지는 않는지도 살펴본다.
• 보기 싫은 코드를 발견하면 리팩터링하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야 한다. (88p)
  
  
• 오랫동안 사람들은 소프트웨어 개발이란 뭔가 ‘추가’하는 과정으로 여겼다.
  기능을 추가하다 보면 대게 새로운 코드를 작성해 넣게 된다. 하지만 뛰어난 개발자는 새 기능을 추가하기 쉽도록 코드를 ‘수정’하는 것이 그 기능을 가장 빠르게 추가하는 길일 수 있음을 안다. (88p)
  
  
• 리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다. ( 92p)
• 리팩터링의 본질은 코드베이스를 예쁘게 꾸미는데 있지 않다. 오로지 경제적인 이유로 하는 것이다. (93p)
  • 리팩터링은 개발 기간을 단축하고자 하는 것이다.
  • 기능 추가 시간을 줄이고, 버그 수정 시간을 줄여준다.
• 테스트 주기가 짧다면 단 몇 줄만 비교하면 되며,
  문제를 일으킨 부분이 그 몇 줄 안에 있기 때문에 버그를 훨씬 쉽게 찾을 수 있다. (97p)
  
  
• 자가 테스트코드와 리팩터링을 묶어서 테스트 주도 개발(Test-Driven Development, TDD)이라 한다. (102p)
  
  
• 하드 리얼타임 시스템을 제외한 소프트웨어를 빠르게 만드는 비결은,
  먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것이다. (103p)
  
  
• 리팩터링을 자동화하는 가장 어설픈 방법은 소스 코드의 텍스트를 직접 조작하는 것이다. (109p)
  • 리팩터링 도구를 사용해서 리팩터링 진행 (ex. 인텔리제이 IDEA)

 

 

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

• 현재 리팩터링을 하고 있는 자그마한 프로젝트가 있는데 거기서 제가 진행하는 리팩터링의 경계가 모호했다는 것을 알게되었습니다.
  • 기능을 추가할 때도 있고, 테스트 코드를 대거 수정할 때도 있었습니다.
    이 책을 읽고 명확하게 어떻게 하는 것이 리팩터링이고 기능 추가인지 알게 되었습니다.
• 리팩터링은 다른 개발자가 내가 작성한 코드를 보다 쉽게 이해하게 도와준다.
  • 내가 작성한 코드를 다른 개발자가 쉽게 이해하게 한다는 것은 결국 시간을 단축시켜준다.
  • 시간을 단축시키면서 회사는 그만큼의 이득을 취하게 된다.
• 내가 작성한 글도 이 책을 다시 읽으면서 리팩터링 해보는 것은 어떨까 생각했습니다.
• 리팩터링은 기능을 구현 할 때도 꾸준히 계속 진행해야 한다는 것을 알게되었습니다.
  • ‘구현을 완료하고 리팩터링을 하자’ 라는 생각이 이 책을 읽기 전까지는 가지고 있었습니다.
• 테스트 코드 하나도 없고 레거시가 줄비한 코드가 적힌 회사에 파견을 나와있습니다.
  • 여기서 문제점은 이런 레거시 코드를 개선하거나 테스트 코드를 추가할 생각을,
    해당 회사 혹은 해당 회사의 개발자가 절대로 하지 않는다는 것 입니다.
• 인텔리제이 도구를 제대로 사용하지 못하고 있다는 것을 알게되었습니다.
  • 리팩터링을 할 때 인텔리제이를 적극적으로 사용해서 진행

 

 

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 리팩터링의 소중함을 무시하고 이해하기 어려운 코드를 짜는 개발자와는 어떻게 일 할까?
• 무조건 커밋을 세세하게 분리하는게 정답은 아닌지?
  • 명확한 이유에서 커밋을 세세하게 분리해야 한다는 걸 이책으로 알게 되었습니다.
  • 단순히 커밋을 세세하게 분리해야 한다는 생각으로 분리하면 안된다.
• 데이터베이스 관련 리팩터링은 전반적으로 이해도가 부족해서 읽기 힘들었습니다. (99P)
  • 아직 공부가 덜 된 것이라고 생각합니다. 차 후에 무조건 다시 읽어야 할 부분입니다.