리팩토링 01

2 분 소요

학습 모듈 및 목차

학습 모듈	목차
리팩토링 개요	- 리팩토링의 필요성 - 코드의 구린내 - 리팩토링의 목표
리팩토링 원리 및 환경	- 객체지향개념 - 테스트의 이해 - 테스트 환경 - TDD(TestDriven Development)
리팩토링 기법1	- 메소드 정리 - 조건문 간결화 - 메소드 호출 단순화
리팩토링 기법2	- 객체간의 기능이동 - 데이터 구조화 - 일반화처리
리팩토링 실습	- 리팩토링 실습(1) - 리팩토링 실습(2) - 리팩토링 실습(3)

리팩토링은 겉으로 드러나는 코드의 기능은 바꾸지 않으면서 내부 구조를 개선하는 방식으로 코드를 수정하는 과정입니다.
리팩토링은 소스의 변경이 쉽게하고 “코드의 구린내”로부터 코드를 지속적으로 깨끗하게 유지하는 방법으로 개발자가 익혀야할 필수적인 습관입니다. (코드품질을 개선하는 객체지향 사고법)

소스코드는 한번에 완성되지 않는다.
- 코딩은 글쓰기, 예술작품처럼 생각을 하면서 실체화한 후 여러 차례 각 부분을 보완하고 다듬어야 완성된다
- 1차적으로는 만들어야하는 목록 -> 목록 순서대로 정리 -> 목록 범위별 묶음 등등
소스코드 작성은 머릿속으로만 생각, 정리하기 힘들다
- 구현요건 이해 -> 기능구현(코딩) -> 간단한 테스트 -> 문서화
- 위와 같이 작업이 진행되지만 만약 모종의 일로 요구사항이 변경되거나 코드를 추가로 더 작성을 해야하는 일이 생겼을 때 영향받는 부분 또는 어느부분까지 코드가 완성되었는지 모를 확률이 매우 높다
소스코드는 끊임없이 변경되고 점점 나쁜코드가 되어간다
- 지속적으로 발생되는 각종 요구사항의 증가와 변경으로 인해 초기 설계, 개발의도와 맞지 않게 변형되고 왜곡되어감
- 계속 누적되는 변형, 왜곡, 덧붙이기로 인해 유지보수가 어려워지고 변경 시 오류발생가능성이 높아짐

나쁜 코드에 대한 기억 -> 이해불가 -> 재개발 -> 차세대 프로젝트
- 프로젝트 중간에 비상투입
- 솔루션개발, 운영 중 타 개발자 업무의 인수인계
왜 나쁜 코드를 짜는가?
- 시간, 일정부족 - 무리한 프로젝트 일정, 허황된 계획
- 성숙하지 못한 SW 문화 - SW 개발 경시, 노동 집약적 SW 개발
- 개발자 잘못된 습관 - “습하니까”, “대충 짜도 돌아간다.”, “나중에 시간 날 때”
- Ownership 부족 - “내꺼 아니니까..”
나쁜 코드의 결과는
- 소스코드 읽는 시간이 증가 - 코드 읽는 시간(90%) vs 코드 작성시간(10%)
- 코딩, 테스트, 디버깅 등 모든 구현작업의 시간 증가 -> 생산성저하, 밤샘근무
- 코드 수정비용 증가, 잦은 오류 발생
- 제품 업그레이드, 출시 주기 증가 -> 시장 경쟁력 상실
- 수년 내 반복되는 재 구축, 차세대 (해외에는 없는 개념)
나쁜 코드를 사용하기 어려운 이유
- 코드는 서로 얽혀있다. (스파게티 코드) -> 잦은 오류 발생
- 계속되는 덧 붙이기 -> 코드 복잡도 증가
- 원 개발의도와 변경된 내용 구별 불가 -> 추가적인 기능 추가, 변경 불가

소스코드 구조가 개선된다. (모듈화, 유지보수성)
- 부적합한 위치에 있는 코드를 제거하거나 적합한 위치로 이동
- 중복코드 제거
소스코드를 이해하기 위워진다. (가독성)
- 소드코드는 모든 팀원들과 공유된다.
- 코딩 작업 중 가장 많은 시간이 소요되는 시간이 소스코드를 읽는 시간이다.
- “우선 창 밖이 보이게 뿌연 유리창부터 닦는 일”
버그를 찾기 쉬워진다. (오류대응)
- 코드 이해가 쉬워지면 버그 발견도 쉬워진다.
- “난 뛰어난 프로그래머는 아니고, 단지 습관을 잘 들인 착실한 프로그래머다”
프로그램 개발 속도가 빨라진다. (생산성)
- 깔끔한 설계, 정리된 코드는 개발 속도를 향상시킨다.

참고 문헌

Refactoring - Martin Fowler
Code Complete - Steve McConnell
Clean Code - Robert C. Martin