자료 출처
- 도서
- 문서
- 확인해야 할 도서 (리팩토링 책에서 소개되는 도서)
- 리팩토링 연습
- 윌리엄 웨이크Williamc. Wake - 「리팩터링 워크북』 (인사이트, 2006)
- 리팩토링과 소프트웨어 디자인 패턴
- 조슈아 케리에프스키Joshua Kerievsky - 「패턴을 활용한 리팩터링」 (인사이트, 2011)
- 특정분야 특화 리팩토링
- 스캇 엠블러Scott Ambler, 프라모드 사달게Pramod Sadalage - 「리팩토링 데이터베이스」 (위키북스, 2007)
- 엘리엇 러스티 해롤드Elliotte Rusty Harold - 「리팩토링 HTML」 (에이콘출판사, 2018)
- 레거시 코드의 리팩토링 (오래된 코드베이스의 리팩토링)
- 마이클 페더스Michael Feathers - 『레거시 활용 전략』 (에이콘출판사, 2018)
- 리팩토링 연습
개요
솔직히 이 책에 수록된 예처럼 간단한 프로그램은 굳이 내가 제시하는 리팩터링들 전부를 적용 할 필요는 없다. 하지만 그 코드가 대규모 시스템의 일부라면 리팩터링을 하고 안 하고의 차이가 크니, 항시 책의 예시들이 대규모 시스템에서 발췌한 코드라고 상상하면서 따라오기 바란다. 이러한 연상 방식은 실전용 기법을 제한된 지면으로 설명하려 할 때 많이들 활용하는 기법이다. (p23)
- 리팩토링을 해야 하는 코드에 대해 알아둔다.
- 리팩토링 기법에 대해 정리한다.
- 코드를 건강하게 관리하기 위해 해야 할 일을 정리한다.
리팩토링?
-
리팩토링은 대부분 코드가 하는 일을 파악하는 데서 시작한다.
-
코드를 읽고
-
개선점을 찾고
-
리팩토링
-
개선점을 코드에 반영
좋은 코드를 가늠하는 확실한 방법은
얼마나 수정하기 쉬운가이다. (p76)
-
-
프로그래머 사이에서 어떤 코드가 좋은 코드인지에 대한 의견은 분분하다.
- 저자의 관점은
수정하기 쉬운 정도로 좋은 코드를 가늠할 수 있다는 것이다.- 코드는 명확해야 한다.
- 코드를 수정해야 할 상황에서 고쳐야 할 곳을 쉽게 찾을 수 있고
- 오류없이 빠르게 수정할 수 있어야 한다.
- 건강한 코드베이스는 생산성을 극대화하고 고객에게 필요한 기능을 더 빠르고 저렴한 비용으로 제공하도록 해준다.
- 코드를 건강하게 관리하려면 프로그래밍 팀의 현재와 이상의 차이에 항상 신경 쓰면서, 이상에 가까워지도록 리팩토링해야 한다.
- 저자의 관점은
⇒ 저자의 관점에 공감한다. 당장에 돌아가는 코드를 구현하여 대응했다면 후에 비슷한 유형의 구현을 해야 할 때 구현되었던 기존 코드를 베이스로 대응할 수 밖에 없어 문제가 불어나게 된다. (기존 코드를 사용하는 방식이 복붙이 되었던, 참고가 되었던간에 발견되지 못한 문제(혹은 외면한 문제)가 그대로 남는다.)
- 리팩토링의 리듬
- 각 단계를 잘게 나누고 다음의 패턴을 가져가야 정확하고 빠르게 처리할 수 있다.
- 수정 가능한 작업을 잘개 쪼개기
- 수정 가능한 최소 단위를 수정하기
- 수정 후에는 컴파일
- 테스트를 작성하여 작동하는 상태 확인
- 한 사이클이 끝나면 commit (git)
- 리팩토링은 결국 "동작을 보존하는 작은 단계들을 거쳐 코드를 수정하고 단계들을 순차적으로 연결하여 변화를 만들어내는 일" 로 정리할 수 있다.
- 각 단계를 잘게 나누고 다음의 패턴을 가져가야 정확하고 빠르게 처리할 수 있다.
리팩토링의 정의
-
명사
리팩터링: ［명사］ 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법
-
동사
리팩터링（하다）: ［동사］ 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러 가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다.
-
리팩토링은 작은 단위로 작업하기 때문에 문제가 있다면 이전 단위로 돌아갈 수 있고, 작업을 중단할 수 있다.
누군가 "리팩토링하다가 코드가 깨져서 며칠이나 고생했다"라고 한다면 십중팔구 리팩토링한 것이 아니다. (p80)
-
재구성 (restructuring) : "코드베이스를 정리하거나 구조를 바꾸는 모든 작업"으로 정리할 수 있다.
- 리팩토링은 재구성 중 특수한 한 형태이다.
-
겉보기 동작 (obervable behavior) : 리팩토링 하기 전과 후의 코드가 똑같이 동작해야 한다. (사용자 관점에서 작업 후에 달라지는 부분이 없어야 하는 것이다.)
- 리팩토링 과정에서 발견된 버그는 리팩토링 후에도 그대로 남아 있어야 한다. (단, 아무도 발견하지 못한 숨은 버그는 수정해도 괜찮다.)
⇒ 리팩토링에서 발견된 버그는 발견했을 때 수정해야 하는게 아닌가 하는 생각이 들었다.
- 리팩토링을 작은 단위로 작업하는 과정에서 버그가 확인된다면 해당 구간을 테스트하고 동작을 확인할 수 있을 때 손볼 수 있기 때문이다. (추후에 버그를 잡으려 전체를 파악하고, 해당 구간을 다시 확인하고, 수정 작업을 위한 시간을 들인다면 정해진 일정 내에 빠르게 대응할 수 있을까?)
- 그러한 점에서 최소 단위 작업에서 확인되는 버그는 리팩토링 작업 후 새로운 수정 작업을 진행하여 정상적으로 동작하도록 해야 한다고 생각한다.
소프트웨어 개발의 목적 두 가지
- '기능 추가'
- 기능 추가 시에는 기존 코드를 건들지 않고 새 기능을 추가하기만 한다.
- '리팩토링'
- 새로운 기능은 추가하지 않고 기존 코드의 재구성에만 전념한다.
- 켄트 백은 이를 두 개의 모자 (two hats)에 비유했다.
- 두 모자의 미묘한 작업 방식의 차이를 분명하게 인식해야 한다.
리팩토링하는 이유
- 리팩토링이 소프트웨어의 모든 문제점을 해결하는 만병통치약은 절대 아니다.
- 하지만
코드를 건강한 상태로 유지하는 데 도와주는 약임은 분명하다.
리팩토링하면 소프트웨어 설계가 좋아진다.
- 리팩토링하지 않으면 소프트웨어의 내부 설계(아키텍쳐)가 썩기 쉽다.
- 아키텍쳐를 충분히 이해하지 못한 채 단기 목표만을 위해 코드를 수정하다 보면 기반 구조가 무너지기 쉽다.
- 코드만 봐서는 설계를 파악하기 어려워진다. → 설계를 유지하기 어려워진다. → 같은 일을 하는 코드를 시멘트 바르듯 중복 코드를 양산한다. → 이해해야 할 코드량이 많아진다. -> 코드만 봐서는 설계를 파악하기 어려워진다. (이하 반복)
- 모든 코드가 언제나 고유한 일을 수행함을 보장할 수 있고, 이는 바람직한 설계의 핵심이다.
리팩토링하면 소프트웨어를 이해하기 쉬워진다.
- 컴퓨터에게 시키려는 일과 이를 표현한 코드의 차이를 최대한 줄여야 한다.
- 잘 동작하지만 이상적인 구조는 아닌 코드가 있다면 잠깐 시간을 내서 리팩토링하는 것이 바람직하다. (계획을 세워서 대응하는 것이 아니다.)
- 이해하기 쉬운 코드는 다른 사람을 배려하는 것과 동시에 미래의 자신에게도 이해를 용이하게 해준다.
- 기억할 필요가 있는 것들은 최대한 코드에 담으려 한다.
=> 버려지는 주석이나 유지되지 않는 문서 등과 같은 문제에 대한 단순한 해결책은 눈으로 보고 바로 이해하기 쉬운 코드를 작성하는 것이라 생각한다. (물론 바로 이해하기 쉬운 코드를 작성하는 것은 어렵다.)
리팩토링하면 버그를 쉽게 찾을 수 있다.
- 리팩토링을 통해 코드가 하는 일을 깊이 파악하게 되면서 새로 깨달은 것을 곧바로 코드에 반영하게 된다.
- 프로그램의 구조를 명확히 다듬으면 '~할 것이다' 하는 가정이 분명하게 드러난다.
- 버그가 발견되면 지나칠 수 없을 정도까지 명확해진다.
리팩토링하면 프로그래밍 속도를 높일 수 있다.
-
리팩토링 → 코드 품질 향상 (일반적인 생각)
-
뿐만 아니라, 리팩토링 → 새로운 기능 추가에 용이해짐, 버그가 명확히 확인됨, 모듈 단위 동작 파악이 쉬워짐 ⇒ 개발 속도 향상
-
지구력 가설 (Design Stamina Hypothesis)
-
내부 설계에 심혈을 기울이면 소프트웨어의 지구력이 높아져 빠르게 개발할 수 있는 상태를 더 오래 지속할 수 있다.
-
처음부터 좋은 설계를 마련하기란 매우 어렵다.
⇒ 처음부터 완벽한 요구사항 파악, 일정 설정, 좋은 성능 확보 등은 절대 불가능하다고 생각한다.
그래서 리팩토링은 반드시 필요하다.
