You Aren't Going To Need It

Hyodduru ·2022년 12월 27일
2
post-thumbnail

Refactoring 2판 마틴파울러 2.5 ~ 정리

리팩터링 시 고려해야 할 문제

  • 특정한 기술, 도구, 아키텍처 등을 내세울 때마다 항상 문제점을 찾는다.

  • 무언가를 언제, 어디에 적용할지 판단하려면 손익을 제대로 이해해야 한다.

새기능 개발 속도 저하

리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다.

  • 기능 추가부터 하고 싶은 상황에 마주칠 수 있다. 이럴 때는 프로 개발자로서 가진 경험을 잘 발휘해서 결정한다.

  • 내가 직접 건들일 일이 거의 없거나, 불편한 정도가 그리 심하지 않다고 판단되면 리팩터링하지 않는 편이다.

  • 개발팀을 이끌고 있다면 코드베이스가 더 건강해지는 것을 추구한다는 사실을 팀원들에게 명확히 밝혀야 한다.

  • 사람들이 빠지기 가장 쉬운 오류는 리팩터링을 클린 코드(clean code)나 '바람직한 엔지니어링 습관'처럼 도독적인 이유로 정당화하는 것이다.

  • 리팩터링의 본질은 오로지 경제적인 이유로 하는 것이다.

    • 개발 시간을 단축하고자 하는 것.
    • 기능 추가 시간을 줄이고 버그 수정 시간을 줄여준다.

코드 소유권

  • 코드 소유권이 나뉘어 있는 경우,
    • 기존 함수도 그대로 유지하되 함수 본문에서 새 함수를 호출하도록 수정할 수 있음.
  • 내가 선호하는 방식은 코드의 소유권을 팀에 두는 것이다. 그래서 팀원이라면 누구나 팀이 소유한 코드를 수정할 수 있게 한다.

브랜치

  • 기능 브랜치 방식의 단점

    • 독립 브랜치로 작업하는 기간이 길어질수록 작업 결과를 마스터로 통합하기가 어려워짐.
    • 이 고통을 줄이고자 많은 이들이 마스터를 개인 브랜치로 수시로 리베이스(rebase)하거나 머지(merge)한다.
  • 기능별 브랜치의 통합 주기를 2~3일 단위로 짧게 관리해야 한다고 주장하는 사람이 많다.

  • 더 짧은 방식을 지속적 통합(Continuos Integration) 또는 트렁크 기반 개발(Trunk-Based Development)이라 한다.

  • CI를 잘 적용하기 위해서는, 마스터를 건강하게 유지하고, 거대한 기능을 잘게 쪼개는 법을 배우고, 각 기능을 끌 수 있는 기능 토글(feature toggle, 기능 플래그 feature flag)을 적용하여 완료되지 않은 기능이 시스템 전체를 망치지 않도록 해야 한다.

  • 켄트 벡이 CI와 리팩터링을 합쳐 익스트림 프로그래밍(eXtreme Programming XP)을 만듬.

테스팅

  • 리팩터링하기 위해서는 (대부분의 경우에) 자가 테스트 코드(self-testing code)를 마련해야 한다.

  • 자가 테스트 코드는 리팩터링을 할 수 있게 해줄 뿐만 아니라, 새 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다.

  • 뛰어난 자동 리팩터링 기능을 제공하는 환경이라면 굳이 테스트하지 않아도 오류가 생기지 않는다고 확신할 수 있다.

  • 자가 테스트 코드는 통합 과정에서 발생하는 의미 충돌을 잡는 메커니즘으로 활용할 수 있어서 자연스럽게 CI와도 밀접하게 연관된다.

레거시 코드

  • 레거시 시스템을 파악할 때 리팩터링이 굉장히 도움된다. => 테스트 보강을 통해 리팩터링할 수 있다.

  • 프로그램에서 테스트를 추가할 틈새를 찾아서 시스템을 테스트해야 함.

데이터베이스

  • 진화형 데이터베이스 설계(evloutionary database design)와 데이터베이스 리팩터링 기법

    • 커다란 변경들을 쉽게 조합하고 다룰 수 있는 데이터 마이그레이션 스크립트를 작성하고, 접근 코드와 데이터베이스 스키마에 대한 구조적 변경을 이 스크립트로 처리하게끔 통합하는 데 있다.
    • 전체 변경 과정을 작고 독립된 단계들로 쪼개는 것이 핵심.
    • 데이터베이스 리팩터링은 프로덕션 환경에 여러 단계로 나눠서 릴리스하는 것이 대체로 좋다는 점에서 다른 리팩터링과 다르다.

리팩터링, 아키택처, 애그니(YAGNI)

  • 수년 동안 운영되던 소프트웨어라도 아키텍처를 대폭 변경할 수 있다.

  • 리팩터링이 아키텍처에 미치는 실질적인 효과는 요구사항 변화에 자연스럽게 대응하도록 코드베이스를 잘 설계해준다는 데 있다.

  • 유연성 메커니즘(flexibility mechanism)의 단점

    • 다양한 예상 시나리오에 대응하기 위한 매개변수들 = 유연성 메커니즘
    • 함수가 복잡해짐.
    • 오히려 변화에 대응하는 능력을 떨어뜨릴 때가 대부분
  • 유연성 메커니즘을 리팩터링을 활용하여 다르게 접근하기

    • 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다.
    • 아키택처도 그에 맞게 리팩터링해서 바꾼다.

위와 같은 설계 방식을 간결한 설계(simple design), 점진적 설계(incremental design), YAGNI(에그니, You aren't going to need it의 줄임말)으로 부름.

리팩터링과 소프트웨어 개발 프로세스

  • 자가 테스트 코드와 리팩터링을 묶어서 테스트 주도 개발(Test-Driven Development)이라 한다.

  • 리팩터링과 YAGNI는 서로 긍정적인 영향을 준다. 리팩터링(과 그 선수 조건들)이 YAGNI의 토대인 동시에, YAGNI로 인해 리팩터링을 더욱 쉽게 할 수 있다.

리팩터링과 성능

  • 리팩터링하면 소프트웨어가 느려질 수도 있는 건 사실이다. 하지만 그와 동시에 성능을 튜닝하기는 더 쉬워진다.

  • 소프트웨어를 빠르게 만드는 비결은, 먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것이다.

  • 빠른 소프트웨어를 작성하는 방법 세 가지

    • 시간 예산 분배(time budgeting) 방식
      설계를 여러 컴포넌트로 나눠서 컴포넌트마다 자원 예산을 할당한다.
    • 끊임없이 관심을 기울이는 것
    • 성능 최적화에 돌입하기 전까지는 성능에 신경 쓰지 않고 코드를 다루기 쉽게 만드는 데 집중한다. 그러다 성능 최적화 단계가 되면 구체적인 절차를 따라 프로그램을 튜닝한다.
      프로파일러로 프로그램을 분석하여 시간과 공간을 많이 잡아먹는 지점을 알아낸다.
      각 단계마다 컴파일과 테스트를 거치고 프로파일러를 다시 실행해본다.
      성능이 개선되지 않았다면 수정내용을 되돌린다.
  • 프로그램을 잘 리팩터링해두면, 성능 튜닝에 투입할 시간을 벌 수 있다.

  • 리팩터링이 잘 되어 있는 프로그램은 성능을 더 세밀하게 분석할 수 있다.

profile
꾸준히 성장하기🦋 https://hyodduru.tistory.com/ 로 블로그 옮겼습니다

0개의 댓글