리팩터링 2판
리팩터링 2판. : 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기
약 500장의 두꺼운 기술서적을 3개월의 시간을 투자해 1회독 했습니다. 개발자 필독서라고 하면 빠지지 않고 올라오는 도서라 도대체 무슨 내용이기에 다들 입을 모아 좋다고 하는지 궁금했거든요. 다행히도 리팩터링 2판은 예시가 JS로 쓰여있어서 더 읽을만 했던 것 같습니다. JAVA로 쓰여있었던 클린코드(로버트 C. 마틴의 책)는 나중엔 조금 휘뚜루 마뚜루 읽어내려갔던 경험이 있었는데 리팩터링은 코드를 꼼꼼히 살펴보며 읽을 수 있었습니다.
그래서 이 책을 읽고 뭔가 달라졌나요?
사실 왕초보 개발자 시절부터 '리팩터링'이라는 말은 자주 써왔었습니다. 그렇지만 지금까지 시니어와 함께 일해본 경험이 없어서 내가 하고 있는 것이 맞는 건지, 어떻게 보면 귀찮고 사소한 작업인데 꼭 해야하는지, 어떤 이유를 들어서 리팩터링을 하도록 팀원을 설득할 수 있을지 등에 대한 고민이 있었는데요. 이 책을 읽으면서 리팩터링에 대한 이유와 방법에 대해서 조금 더 명확하게 이해할 수 있었습니다. 가장 큰 변화는 지금까지 회사에서 잘못 사용하고 있었던 '리팩터링'에 대한 개념을 바로잡을 수 있었습니다.
- refact: {
- description:
- '기존 로직 수정, 코드 형태 변경, 코드 재구성 등을 포함한 리팩토링',
- title: 'refact',
- },
+ refact: {
+ description:
+ '동작은 동일하나 내부 로직이 변경된 리팩토링',
+ title: 'refact',
+ },
사내에서 쓰는 커밋 템플릿 라이브러리의 정의를 위와 같이 바꾸었어요. 이전에는 무에서 유를 만들면 feature고, 이미 있는 것을 수정하면 리팩터링이라고 생각했었는데 리팩터링에 대한 의미가 명확해졌습니다.
그리고 책에 나오는 예시 코드들을 보면서 커밋을 좀더 세부적으로 가져가는 연습을 시작했습니다. 눈에 보이는대로 고친 후에 뭉뚱그려서 커밋을 하곤 했었는데 이젠 리팩터링 기법을 하나하나 생각해보며 커밋을 작성하고 있습니다.
책에서 내내 컴파일 -> 테스트 -> 커밋 과정을 강조하는데 덕분에 테스트 코드를 작성하는 것에 대한 관심도 생겼습니다. 리팩터링에 선행되어야하는 것은 테스트코드라는 것을 알 수 있었어요. 이 내용들을 잘 전파해서 5~6월엔 사내 테스트코드 스터디도 진행할 수 있었답니다 :)
책을 읽고 나서 달라지지 않은 부분도 있습니다.
코드리뷰를 할 때, '이게 리팩터링 예제 코드 였다면 십중팔구 마틴 파울러 선생님께서 고치셨을텐데...'라고 생각한 부분이 종종 있습니다. 이러저러한 이유로 고치는 게 좋겠다고 리뷰를 달지만 팀원들을 충분히 설득시키지 못하는 이유일 때가 많아서 매번 아쉬움이 남는데요. 책을 읽고 나서도 명확한 이유를 들어서 리팩터링을 하도록 설득하는 것은 여전히 어렵습니다. 클래스, 상속, 인터페이스 등 객체지향적인 부분에 대해서는 아직도 많이 부족하다는 것을 느꼈습니다. 솔직히 이해되지 않아서 빠르게 넘긴 챕터들도 있습니다. 아직 회사에서 쓰는 코드에도 그런 부분들은 많이 없다보니 실전에서 연습해 볼 일도 많이 없었는데 언젠간 클래스를 활용해서 피쳐를 만들어보는 연습을 해보아야겠네요. 아직도 객체지향 패러다임은 낯선 부분이 많습니다.
기억하고 싶은 문장들
- 리팩터링하기 전에 제대로 된 테스트부터 마련한다.
- 리팩터링은 프로그램 수정을 작은 단계로 나눠서 진행한다. 그래서 중간에 실수하더라도 버그를 쉽게 찾을 수 있다.
- 자바스크립트와 같은 동적 타입 언어를 사용할 때는 타입이 드러나게 작성하면 도움된다. 접두어로 타입 이름을 적는다거나… 매개변수 역할이 뚜렷하지 않을 때는 a/an을 붙인다.
- 반복문이 중복되는 것을 꺼리는 이들이 많지만, 이정도 중복은 성능에 미치는 영향이 미미할 때가 많다. 리팩터링 과정에서 성능이 크게 떨어졌다면 리팩터링 후 시간을 내어 성능을 개선한다. 리팩터링 덕분에 성능 개선을 더 효과적으로 수행할 수 있다. 따라서 리팩터링으로 인한 성능 문제에 대한 내 조언은 ‘특별한 경우가 아니라면 일단 무시하라’는 것이다.
- 좋은 코드를 가늠하는 확실한 방법은 ‘얼마나 수정하기 쉬운가’다.
- 취향을 넘어서는 관점이 분명히 존재한다. 코드는 명확해야한다.
- 지금껏 수많은 사람이 코드를 정리하는 작업을 모조리 ‘리팩터링’이라고 표현하고 있는데, 특정한 방식에 따라 코드를 정리하는 것만이 리팩터링이다. 누군가 “리팩터링하다가 코드가 깨져서 며칠이나 고생했다”고 한다면, 십중팔구 리팩터링한 것이 아니다.
- 리팩터링 과정에서 발견된 버그는 리팩터링 후에도 그대로 남아 있어야 한다.
- 리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이다.
- 시스템에 대해 잘 알더라도 섣불리 추측하지 말고 성능을 측정해봐야 한다.
- 코드에서는 명확함이 핵심이다. 반환점이 하나일 때 함수의 로직이 더 명백해진다면 그렇게 하자. 그렇지 않다면 하지 말자.
- 가변 변수를 제거하면 자다가도 떡이 생긴다!(푸핫.. 파울러 아저씨… 미국엔 떡 없잖아요!)
기술 서적 읽기를 포기하지 않는 나만의 노하우
사실 이 책도 작년 11월쯤 읽으려고 했다가 1장 읽고 무기한 연기되었던 전적이 있습니다. 기술 서적 읽기는 생각보다 진도가 쭉쭉 나가지 않아서 눈 깜빡하면 1달이 지나있는 경우가 많았어요. 하지만 이번에는 3개월만에 읽어낼 수 있었습니다!
- 기술 서적 읽기 모임
- 책을 읽기 전에 예제 코드를 먼저 리팩터링 해보기
1. 기술 서적 읽기 모임
책 읽기를 좋아하는 친구와 함께 독서 모임을 시작했습니다. 일주일에 2회, 한번에 10페이지 이상 읽고 인증하는 모임인데요. 생각보다 효과가 좋아서 2차 모임을 진행 중에 있습니다. 각자 다른 책을 읽었기 때문에 리팩터링에 대한 다양한 의견을 나누지는 못했지만 다른 사람들은 어떤 방식으로 기술 서적을 읽어나가는지 알 수 있어서 재미있었어요. 독서 모임을 주최할 상황이 되지 못할 때에도 주기적으로 책을 읽는 시간을 가지고, 읽을 때마다 읽은 부분에 대해서 요약하는 방식으로 읽어나가는 것도 좋은 방법이라고 생각합니다.
2. 책을 읽기 전에 예제 코드를 먼저 리팩터링 해보기
'함수 추출하기' 기법 예제코드를 보고 먼저 리팩터링을 해보고 나서, 저자는 어떤 방식으로 리팩터링 했는지 살펴보았습니다. 저와 비슷하게 생각한 부분도 있었고 그렇지 않은 부분도 있었는데 기술 서적에 대한 흥미를 잃지 않게 해주고 기억에 더 오래 남을 수 있게 해주는 방식인 것 같아요. 훌륭한 개발자와 비슷한 방식으로 사고했다는 것에서 자신감을 얻을 수 있었고, 그렇지 않은 부분에 있어서는 배워갈 수 있어서 보람찼습니다. 리팩터링 1판은 JAVA로 쓰여있어서 그런지 몰라도 객체지향적인 부분이 꽤 많았습니다. 지금껏 JS를 쓰면서 많이 활용하지 않았던 클래스와 상속도 많이 다루고 있고요. 이 부분은 다시 한번 공부해야겠다는 생각이 들었습니다.
부록
저자의 추천도서
- 리팩터링 워크북
- 패턴을 활용한 리팩터링
- 리팩토링 HTML
- 레거시 코드 활용 전략
- 리팩터링 자바스크립트