[리팩토링] 2 ~ 5장

enrichPerformance 메서드에서 shallow copy한 Performance 객체에 동적으로 play라는 필드를 추가해버리는데 자바에서는 어떻게 구현하셨는지 궁금합니다

(p.56)

 

• PerformanceVo 별도로 정의
• Performance 클래스에 추가

 

 

데이터베이스 리팩토링 or 마이그레이션 시 얼마나 작은 단계로 나눠서 릴리스 하시는지 궁금합니다

(p.99)

 

• flyway 사용
• DBA 검수 이후 주로 오전에 배포합니다. 락이 걸리거나 큰 작업의 경우에는 새벽에 배포합니다.
• DBA에게 요청합니다. 2주에 한번씩 주기적으로 한번에 배포합니다.

 

 

모든 상황에서 기능 추가와 리팩토링을 독립적으로 분리하여 커밋하기에는 너무 피곤해질 것 같은데..

그럼 기능 추가를 진행하며 마음에 들지않는 코드여도 일단 내버려두고, 작업을 마친 뒤에 리팩토링 시간을 따로 가지시나요?

(2장. 두 개의 모자)

 

• 처음 기능 추가할 때는 한 메서드 내에서 만들어요. 디버깅도 쉽고, 변화도 별로 없어서요. 다만 커밋 후에는 메서드 추출 등을 활용해서 리팩토링을 시작합니다.
• 기능 추가와 리팩토링 간 브랜치를 나누지는 않고 마이크로 커밋으로 하면 크게 피곤하지는 않았던 것 같습니다.

 

 

"코드가 한 줄이어도 따로 설명할 필요가 있다면 함수로 추출하는게 좋다. 조건문이나 반복문도 추출 대상의 실마리를 제공한다." 라는 구문에서는 대부분의 상황에서 의미 부여가 가능하다면 함수로 추출하는 것을 권장하는 것 같습니다.

책의 예시처럼 한 줄의 코드라도 메서드 추출을 활용하시는 편인가요?

(p.116)

 

• 코드 리뷰를 하긴 하는데, 한 줄로 작성된 메서드는 못본 것 같습니다.
• 게임 서버에서는 함수 추출을 대부분 안하신다. 하드 코딩 되어있는 부분이 상당히 많은데, 이를 리팩토링 해보려다 실제로 피 본 경험이 있습니다.

 

 

TDD를 실무에서 각 잡고 실행하는 사례를 보신 적이 있으신가요?

(4장. 자가 테스트 코드의 가치)

 

• 빠르게 기능이 개발되어야 하는 팀에서는 불가능할 것 같습니다. 기획 사양이 주기적으로 변하는 경우가 많아서 팀원들이 테스트 코드를 많이 작성하는 것에 대해 부정적인 견해를 가지기도 하는 것 같고요.
• 신생 스타트업에서만 가능할 것 같습니다.
• 팀 내에 'TDD는 허상이다'라고 구체적인 근거를 토대로 주장하시는 팀원분들도 계십니다. 실제로 TDD를 창시한 켄트 벡도 무조건적인 TDD는 옳지 않다고 말한 것으로 알고 있습니다.
• 알파) 참고 자료
  https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565

How deep are your unit tests?

 

 

별도로 intellij plugin 추천드립니다

• sonarlint : 정적 분석 플러그인
• checkstyle : 스타일 강제
• code metrics : 코드 복잡도 표시, 권장 6 이하
• GraalVM 사용
• translation : 번역 팝업