자바의 final키워드를 메서드 파라미터, 지역변수에 까지 활용하는 것이 좋을까?

[Libienz]

구구의 미션에서 제공되는 코드들은 메서드 파라미터에 final 키워드를 사용하고 있고 지역변수에도 final 키워드가 사용되고 있다.
이러한 형태가 가지는 장점과 단점을 중심으로 각자의 의견을 이야기해보자.

[Libienz]

리비 발제 의도

우테코 레벨 4미션들에서 제공 받은 스켈레톤 코드에는 메서드 파라미터와 지역 변수에 final 키워드가 존재했다. 이전에도 이러한 구현을 본 적이 꽤 있다. 하지만 그만큼 final 키워드를 메서드 파라미터나 지역 변수에 사용하지 않는 개발자들도 많아서 스터디원들은 어떻게 생각하는지 의견 나눠보고 싶어 발제한다. 각자의 의견과 각자가 그렇게 의견을 가지게 된 중심이 되는 장단점들을 이야기하면서 서로를 설득하는 과정을 가져보자.

---

참고 final 키워드 사용 예시

@Override  
public void onStartup(final ServletContext servletContext) {  
  final var dispatcherServlet = createDispatcherServlet();  
  
  final var registration = servletContext.addServlet(DEFAULT_SERVLET_NAME, dispatcherServlet);  
  if (registration == null) {  
  throw new IllegalStateException("Failed to register servlet with name '" + DEFAULT_SERVLET_NAME + "'. " +  
  "Check if there is another servlet registered under the same name.");  
 }  
  registration.setLoadOnStartup(1);  
  registration.addMapping("/");  
  
  log.info("Start AppWebApplication Initializer");  
}

리비 의견: final 키워드를 메서드 파라미터와 지역 변수에 사용하지 않는다.

final 키워드는 사실 불변을 보장하는 듯 하지만 객체의 참조 불변성만 제공한다. 곳곳에 사용된 final 키워드는 들여쓰기를 깨트리고 핵심 로직 주위를 둘러싸서 코드 가독성을 흐린다. 그래서 나는 final 키워드를 사용하지 않고 있다.

에버 의견: final 키워드를 메서드 파라미터와 지역 변수에 사용하지 않는다.

인텔리제이가 많은 부분을 자동화해주어도 final 코드는 여전히 작성이 번거롭다. 팀 프로젝트 상황에서 지켜야할 컨벤션이 하나 느는 것은 언제나 비용이 든다. final을 통해서 얻을 수 있는 장점이 그렇게 크다고 생각하지 않기 때문에 나도 final 키워드를 사용하지 않고 있다.

제리 의견: final 키워드를 메서드 파라미터와 지역 변수에 사용하지 않는다.

내게는 코드 인덴트가 아주 아주 중요하다. 매개 변수에 final이 붙어서 줄바꿈이 생긴다면 굉장히 불편하다. 사실 이는 코드 가독성 저하로 이어질 수 있다고도 생각한다. 진행중인 프로젝트에서도 final 키워드에 대한 선호도가 높지 않아 적용하지 않고 있다.

콜리 의견: final 키워드를 메서드 파라미터와 지역 변수에 사용하지 않는다.

final 키워드는 참조의 불변성만 제공해서 개발자에게 혼란을 줄 수 있으며 (불변 객체로 오해) 다른 인원들이 말해준 것 처럼 불필요한 정보를 과다하게 한다. 또한 리팩토링과 테스트를 어렵게 하여 개발 생산성을 저하하기에 나도 선호하지 않는 방식이다.

모두가 반대!? 가상의 찬성 인물을 세워보자

콜리: 모두의 의견이 모였다~ 토론 진행을 위해서 가상의 찬성 인물을 세우고 토론을 진행해보면 좋을 것 같다. final 키워드의 장점을 근거로 내가 가상의 찬성 인물이 되어 보겠다.

final 키워드는 불변성을 보장한다는 측면에서 중요하다.

콜리: final 키워드는 해당 변수가 불변하다는 것을 보장한다. 이는 다른 개발자의 실수를 막는데 도움을 주며 공통된 이해를 가지는 개발자들에게 명세로 받아들여질 수 있어 강력하다. 명세로서의 final 키워드의 장점에 대해서 다들 어떻게 생각하는가?

리비: 사실 final 키워드는 참조 불변성만 제공한다. 완전한 불변을 제공하려면 불변 객체등이 추가로 운용되어야 의미가 있다. 반쪽짜리 불변성을 위한 final 키워드가 그렇게 의미 있는지 잘 모르겠다.

제리: 리비의 의견에 동감한다. 사실 정말 불변하기를 원한다면 final을 통해서 틀어막는 것보다 다른 기술을 사용하는 것이 의미있다고 생각한다.

객체의 상태 변경은 감지하지 못하더라도 참조 불변, 그 자체로 의미 있다.

콜리: final 키워드가 객체의 상태 변화를 감지하지 못한다는 것은 모두가 말한 것처럼 사실이다. 하지만 참조 불변성을 보장한다는 의미가 중요하지 않지는 않다. 다른 개발자가 의도를 파악하기 쉽게 하기 위한 측면에서 메서드 명세는 자세할 수록 좋다. 바뀌면 안될 것을 바뀌면 안된다라고 설명하는 것에 나는 위화감이 없다고 생각한다. 그리고 코드 동작을 예측 가능하게 하는 것도 final 키워드의 좋은 점 중 하나라고 생각한다.

에버: 우리는 객체지향 생활 체조 원칙, 불변 객체 등 좋은 자바 프로그래밍 기법에 대해서 학습했다. 이것을 잘 지키는 것으로 애플리케이션의 오동작을 충분히 막을 수 있다고 생각한다. 이미 효율적인 방어선이 많이 있는데 반쪽짜리 솔루션이 필요한지 나도 의문이다.

제리: 다른 개발자가 작성한 메서드를 유지보수해야 하는 경우를 생각해보자. 유지보수하는 개발자는 우선 메서드의 명세를 살필 것 같다. 그 때 개발자는 보통 상세 구현보다는 메서드 시그니처를 가장 먼저 살핀다.(메서드 이름, 메서드 반환 타입, 파라미터) 메서드 시그니처를 통해 어떤 동작을 하는 메서드인지 파악한다면 그 후에 유지보수를 진행할 것이다. 객체 지향의 멋진 점 중 하나는 캡슐화인데 만약 유지보수해야할 메서드에 final 키워드가 덕지덕지 있다면 유지보수하는 개발자는 구현 방식의 제한을 느끼게 된다. 이는 점진적 리팩터링을 방해하고 결과적으로 유지보수를 방해할 수 있어 오히려 역효과가 있다고 생각한다.

final 키워드는 컴파일 성능을 향상시킨다.

콜리 의견: final 키워드를 사용하면 컴파일 성능이 향상된다. final 키워드를 사용하면 컴파일러가 해당 변수가 변경되지 않음을 알 수 있어 다양한 최적화를 적용할 수 있다. 이는 결과적으로 컴파일 시간 단축과 실행 성능 향상으로 이어질 수 있다. 특히 루프 내에서 사용되는 변수에 final을 적용하면 JIT 컴파일러가 더 효율적인 바이트코드를 생성할 수 있다.

에버 의견: 컴파일 성능 향상은 미미하다. 컴파일러의 최적화 능력은 이미 매우 발전되어 있어 final 키워드 없이도 대부분의 최적화를 수행한다. 실제로 final 키워드로 인한 성능 향상은 측정하기 어려울 정도로 미미하다. 개발자가 코드의 복잡성을 높이면서까지 이점을 취하려는 것은 효율적이지 않다고 생각한다.

제리 의견: 나도 성능 향상은 체감하기 어렵다고 생각한다. 실제 프로젝트에서 final 키워드를 사용하여 성능이 눈에 띄게 향상된 사례를 본 적이 없다. 현대의 JVM은 코드 분석을 통해 자동으로 최적화를 수행하므로, final 키워드로 인한 성능 향상은 거의 없다고 본다. 오히려 코드의 가독성을 해치지 않는 것이 더 중요하다.

리비 의견: 마찬가지로 성능보다 코드 유지보수가 더 중요하다고 생각한다. 성능 최적화를 위해 final 키워드를 사용하는 것은 과도한 최적화라고 생각한다. 미미한 성능 향상을 위해 코드의 유연성과 가독성을 포기하는 것은 바람직하지 않다. 실제로 성능 이슈가 발생한다면 그때 프로파일링을 통해 최적화하는 것이 더 효율적이다.

final 키워드는 테스트 코드, 리팩터링 등의 개발 영역에서 유연성을 제한한다.

리비 의견: final 키워드를 사용하면 모의 객체나 스파이를 활용한 테스트가 어려워질 수 있다. 특히 메서드 파라미터나 지역 변수가 final이면 리플렉션을 사용하여 값을 변경하는 것도 불가능하다. 또한 점진적 리팩터링의 과도기 단계에서는 코드 구조 레벨에서의 유연함이 필요한데 final 키워드는 이러한 유연함을 허용하지 않는다.

콜리 의견: 오히려 리팩터링 시 안정성을 높일 수 있다고 생각한다. 코드를 리팩터링할 때 final 키워드를 사용하면 변수의 불변성이 보장되어 예기치 않은 변경을 방지할 수 있다. 이는 코드 수정 시 실수를 줄이고, 의도하지 않은 부작용을 예방하여 작업 효율을 높인다. 변수의 값이 변경되지 않음을 명확히 표현함으로써 코드의 안정성과 신뢰성을 향상시킬 수 있다. 따라서 final 키워드를 적절히 사용하여 리팩터링 과정에서의 오류를 최소화하는 것이 바람직하다. 과도기에 대해서 이야기했지만 아직까지 맥락을 느껴보지 못했다. 유연함은 인터페이스를 활용한 다형성이라는 좋은 무기가 있으니 이를 사용하면 되지 않나?

final 키워드는 개발 생산성을 저하시킨다.

제리 의견: 개발 속도가 느려진다. 모든 변수에 final 키워드를 붙이는 것은 개발자의 부담을 증가시킨다. 코드 작성 시간이 늘어나고, 가독성도 떨어진다. 이는 전체적인 개발 생산성 저하로 이어질 수 있다. 핵심 로직 구현에 집중하는 것이 더 중요하다고 생각한다.

리비 의견: 팀 내 협업에 방해가 된다. 팀원들마다 코딩 스타일이 다를 수 있는데, final 키워드 사용에 대한 합의가 이루어지지 않으면 코드 일관성이 떨어진다. 이는 코드 리뷰나 협업 과정에서 불필요한 논쟁을 일으킬 수 있다. 생산성을 높이기 위해서는 팀 내에서 간결하고 일관된 코딩 규칙을 정하는 것이 좋다.