[리팩터링] 챕터01. 리팩터링: 첫 번째 예시

 

 

 

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

• 리팩터링이란?(7p)
  겉으로 드러나는 코드의 기능(겉보기 동작)은 바꾸지 않으면서 내부 구조를 개선하는 방식으로
  소프트웨어 시스템을 수정하는 과정이다.
  
  
• 프로그램이 새로운 기능을 추가하기에 편한 구조가 아니라면, 먼저 기능을 추가하기 쉬운 형태로 리팩터링하고 나서 원하는 기능을 추가한다.(27p)
  
  
• 리팩터링하기 전에 제대로 된 테스트부터 마련한다. 테스트는 반드시 자가진단하도록 만든다.(28p)
  
  
• 조금씩 수정하여 피드백 주기를 짧게 가져가는 습관이 이러한 재앙을 피하는 길이다.(32p)
  
  
• 리팩터링은 프로그램 수정을 작은 단계로 나눠 진행한다.
  그래서 중간에 실수하더라도 버그를 쉽게 찾을 수 있다.(32p)
  
  
• 하나의 리팩터링을 문제없이 끝낼 때마다 커밋한다.
  그래야 중간에 문제가 생기더라도 이전의 정상 상태로 쉽게 돌아갈 수 있다.(33p)
  
  
• 컴퓨터가 이해하는 코드는 바보도 작성할 수 있다.
  사람이 이해하도록 작성하는 프로그래머가 진정한 실력자다.(35p)
  
  
• 임시 변수는 나중에 문제를 일으킬 수 있다. 임시 변수는 자신이 속한 루틴에서만 의미가 있어서 루틴이 길고 복잡해지기 쉽다.(42p)
  • 함수를 직접 선언해 사용하도록 바꾼다.
    
    
• 긴 함수를 작게 쪼개는 리팩터링은 이름을 잘 지어야만 효과가 있다.(44p)
  • 처음에는 당장 떠오르는 최선의 이름을 사용하다가 나중에 더 좋은 이름이 떠오를 때 바꾸는 식이 좋다.
    흔히 코드를 두 번 이상 읽고 나서야 가장 적합한 이름이 떠오르곤 한다.
    
    
• 리팩터링은 대부분 코드가 하는 일을 파악하는 데서 시작한다.(76p)
• 좋은 코드를 가늠하는 확실한 방법은 ‘얼마나 수정하기 쉬운가’다(76p)

 

 

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

• 리팩터링을 하기 위해서는 테스트 코드들 부터 마련해야 한다는 말이 정말 공감됩니다.
  저자의 말대로 사람은 실수를 할 수 있기 때문에 테스트 코드를 통해 수정된 코드를 검증 할 수 있습니다.(28p)
  
  
• 변수명을 축약해서 작성한 것을 많이 봤습니다.
  해당 프로젝트를 진행 할 때 변수명의 의미를 파악하는데 시간을 상당히 많이 소비했습니다.
  
  
• perf라는 변수는 해당 코드를 처음보면 무슨 의미인지 알기 힘들 것 같다고 느꼈습니다.
  
  
• 깃에 커밋 푸쉬를 하는데 코드를 뭉텅이로 하는 사람을 봤습니다.
  결국에 그 사람은 버그가 생겼을 때 해당 버그를 찾는데 엄청난 시간을 쏟았습니다.
  커밋을 잘게 나누는게 정말 중요하다고 느낀 계기였습니다.
  
  
• 책이 되게 친절하게 잘 적혀있었습니다.
  하나의 함수로 작성된 코드를 리팩터링 한 부분을 화살표로 표시해준게 정말 좋았습니다.

 

 

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

• 대규모 프로젝트에서는 어떻게 리팩터링을 진행하는지 궁금했습니다.
• 변수명을 축약해서 나타내는 회사들이 많습니다.
  전문용어들의 의미를 변수명에 담을려고 하니까 그렇지 않을까 생각했습니다.
  이런 문제를 어떻게하면 더 좋게 해결할지 궁금했습니다.
  
  
• 얕은 복사와 깊은 복사를 한번 배웠었는데 리팩터링에도 같은 내용이 나왔습니다.
  하지만 해당 내용에 대해 아직 이해가 덜 되어서 이해하는데 조금 힘이 들었습니다.
• 다형성 부분은 한번 더 봐야 할 것 같습니다.