02. 리팩토링 원칙
리팩토링의 정의#
"리팩토링하다가 코드가 깨져서 며칠이나 고생했다"는 말은 리팩토링이 아니다.
리팩토링은 언제든 코드가 정상 동작 해야하며, 전체 작업이 끝나지 않더라도 언제든 멈출 수 있다.
리팩토링 과정에서 발결된 버그는 리팩토링 후에도 그대로 남아있어야 한다. (단 아무도 발견하지 못한 숨은 버그는 수정해도 된다 ㅋㅋ)
리팩토링은 사용자 입장에서 봤을 때 리팩토링 전,후가 같아야한다.
두 개의 모자#
기능을 추가할 때는 기능 추가의 모자를 써야한다.
리팩토링을 할 때는 리팩토링의 모자를 써야한다. ( 기능 추가는 절대 하지 않을 것이며, 코드 재구성에만 전념한다. )
리팩토링의 이유#
주기적인 리팩토링은 소프트웨어의 설계를 향상 시킨다.
결국은 코드는 인간이 읽기 때문에 인간이 읽기 쉽고 변경에 용이한 구조로 리팩토링 해야한다.
마틴 파울러는 게으른 개발자다. 그래서 자신이 작성한 코드를 머리에 넣어두지 않는다. 단 기억할 필요가 있는 것들은 최대한 코드에 남겨둔다.
리팩토링하면 버그를 쉽게 찾을 수 있다#
- 코드를 이해하기 쉽다는 말은 버그를 찾기 쉽다는 말과 일맥상통한다.
리팩토링하면 프로그래밍 속도를 높일 수 있다#
리팩토링은 코드 개발 속도를 높여준다.
새로운 기능을 추가하는데 더 많은 시간이 걸린다면 리팩토링이 필요한 시점이다.
리팩토링의 타이밍#
- 그러면 언제 리팩토링을 하는 것이 베스트 타이밍일까?
리팩토링의 시점#
- 마틴파울러의 3의 법칙
기능을 쉽게 추가할 수 있게 만들기#
- 함수 매개변수화하기로 중복 줄이기
이해하기 쉬운 코드를 위한 리팩토링#
변수 이름 수정, 함수 이름 수정
긴 함수는 잘게 쪼개보기
수시로 하는 리팩토링#
지나가다가 쓰레기를 줍듯이 리팩토링을 한다.
오래 걸리는 리팩토링은 체크해두었다가 나중에 한다.
오래 걸리는 리팩토링#
대규모 리팩토링은 일부를 조금씩 개선하자.
각 잡고 전체 개발자들이 달려들어서 리팩토링을 하는 짓은 좋지않다.
코드 리뷰에 리팩토링 활용하기#
코드 리뷰를 정기적으로 수행해서 깔끔한 코드 퀄리티를 유지하게 한다.
Pull Request 기반의 코드리뷰 보다는, 코드 작성자를 옆에 앉혀놓고 코드를 보며 이야기 하면서 리팩토링하는 짝 프로그래밍이 더 좋다.
관리자에겐 뭐라고 하지?#
프로 소프트웨어 개발자는 효과적인 소프트웨어를 최대한 빨리 만드는 것이다.
리팩토링은 소프트웨어를 빠르게 만드는데 아주 효과적이다.
프로 개발자에게 주어진 임무는 새로운 기능을 빠르게 구현하는 것이고, 가장 빠른 방법은 리팩토링이다.
리팩토링을 하지 말아야할 때#
- 호출해서 쓰는 코드라면 너저분하더라도 굳이 리팩토링 하지 않는다.
리팩토링 시 고려할 문제들#
- 리팩토링은 만병통치약이 아니다. 리팩토링에 딸려오는 문제들도 있다.
새 기능 개발 속도 저하#
리팩토링의 궁극적인 목적은 개발 속도를 높여서 더 적은 노력으로 많은 가치를 창출하는 것이다.
그러므로 더 자주 리팩토링을 하자.
코드 소유권#
코드 소유권이 나누어져있으면 리팩토링에 방해가 된다.
클라이언트에 영향을 주지 않는 선에서 개발해야하는데 이게 쉽지 않다.
이를 해결하기 위한 원활한 방법은 팀에게 코드 권한을 주는 것이다.
어떤 팀은 다른 팀 사람이 자기 팀 코드의 브랜치를 따서 수정하고 커밋을 요청하는, 흡사 오픈소스 개발 모델을 권장하기도 한다. ( 큰 시스템을 개발할 때 이 모델 좋아보인다. )
브랜치#
여기서는 빈번한 마스터 브랜치의 통합을 통해 마스터와 브랜치간의 양방향 통합을 최소화하는 방향을 설명한다.
대표적으로
Github-flow가 여기에 해당할 듯 하다.기능별 브랜치가 나쁜 것은 아니지만 오래 두면 마스터와 간격이 벌어지고, 해당 기능의 배포가 늦어진다.
고로 가급적이면 매일 마스터에 머지할 수 있는 방향으로 개발하는 편이 좋다고 한다.
테스팅#
리팩토링의 핵심
리팩토링은 전,후에 프로그램의 겉보기 동작이 같아야한다.
이를 검증하기 위한 도구가 바로 테스트다.
요즘은 CI시에 통합 테스트를 넣어서 배포 전에 안전한지를 검증하게 한다.
레거시 코드#
레거시 코드를 개선할 때 리팩토링 + 테스트가 큰 힘을 발휘한다.
코드는 역시 캠핑 규칙에 따라 처음 왔을 때 보다 깨끗해야한다.
레거시 시스템의 규모가 클 수록 리팩토링은 코드를 이해하고 개선하는데 큰 도움이 된다.
데이터베이스#
- 과거에는 JDBC를 사용해 Native SQL Query로 DB를 조작하였지만, 요즘은 ORM이 대세이므로 해당 내용은 조금은 구식인 내용이다.
리팩토링 아키텍처, YAGNI(야근이.. 리팩토링은 야근...?)#
리팩토링은 앞의 상황을 예측하는 것이 아닌, 현재 상황에서 요구사항을 가장 잘 대응할 수 있게 변경하는 것이다.
이런식으로 설계하는 방식을 간결한 설계, 점진적 설계, YAGNI(you aren't going to need it) 등으로 부른다.
리팩토링과 소프트웨어 개발 프로세스#
테스트 코드 + 리팩토링 => TDD
추측에 근거한 수많은 유연성 메커니즘은 때때로 독이 된다.
현재의 요구사항을 만족하는 단순한 시스템을 만들고 추후에 변경이 필요할 때 변경한다. 이것이 바로 YAGNI
리팩토링과 성능#
리팩토링을 한다고 해서 반드시 성능이 떨어지는 것은 아니다.
프로그래머는 계속해서 소프트웨어에 관심을 기울여서 성능에 이슈가 있는지를 면밀이 확인해봐야한다.
성능은 직접 측정해봐야 안다. 내가 추측하는 것은 십중팔구 틀릴 확률이 높다.
리팩토링의 유래#
리팩토링의 유래는 정확히 알 수 없다.
리팩토링은 단순히 코드를 깔끔히 하는 것을 넘어, 소프트웨어 개발 단계의 필수 과정으로 인식되고 있다.
리팩토링 자동화#
- IDE의 도움을 받으면 리팩토링을 조금 더 편리하게 할 수 있다. (젯브레인 최고)
Reference#
- Refactoring 2판 ( 저자 : 마틴 파울러 )