전체 글

Refactoring with SonarLint - Repository

SonarLint라는 툴이 권장하는 방향으로 코드 리팩토링을 하면서 리팩토링 규칙들을 기록하는 글입니다! 중복되는 규칙들은 한 번만 작성하였습니다. 💡 BuildingCustomRepositoryImpl 반복되는 문자열 리터럴을 상수로 정의하라 private static final 키워드로 상수를 정의하여 코드에 반영했습니다. final vs static final final만 사용하면 해당 필드는 변경이 불가능하지만 클래스의 각 인스턴스마다 그 필드의 복사본이 생성됩니다. 이는 필요 이상으로 메모리를 사용하게 되므로, 특히 그 필드의 값이 모든 인스턴스에서 동일할 경우, 비효율적일 수 있습니다. static final을 사용하면 해당 필드는 클래스 레벨에서 한번만 초기화되며 모든 인스턴스에서 공유하게 ..

Refactoring with SonarLint - Service

SonarLint라는 툴이 권장하는 방향으로 코드 리팩토링을 하면서 리팩토링 규칙들을 기록하는 글입니다! 중복되는 규칙들은 한 번만 작성하였습니다. 💡 BuildingServiceImpl 사용하지 않는 메소드 파라미터는 삭제하라 해당 메소드 자체를 사용하지 않아서 삭제했습니다. // Noncompliant Code public Building updateBuilding(BuildingOptionalDto buildingOptionalDto) { return null; } 💡 FileProcessServiceImpl replaceAll 함수를 호출하는 대신 replace 함수를 호출하라 replace 함수로 대체했습니다. 설명 String::replaceAll 메소드는 호출될 때마다 java.util.re..

Refactoring with SonarLint - Controller

SonarLint라는 툴이 권장하는 방향으로 코드 리팩토링을 하면서 리팩토링 규칙들을 기록하는 글입니다! 중복되는 규칙들은 한 번만 작성하였습니다. 💡 BuildingRestController 하나의 파라미터만 가지는 람다이면 파라미터의 괄호를 없애라 // Noncompliant Code (building) -> BuildingSerializer.toBuildingListResponse(building) // Compliant Solution building -> BuildingSerializer.toBuildingListResponse(building) 람다를 메소드 참조로 바꿔라 // Noncompliant Code building -> BuildingSerializer.toBuildingListRe..

이펙티브 자바 - 10장. 예외

10장 - 예외 💡 예외는 진짜 예외 상황에만 사용하라 “예외를 정상적인 제어 흐름에서 사용해서는 안 된다.” 1. 예외를 잘못 사용한 예 // 예외를 완전히 잘못 사용한 예 try { int i = 0; while(true) range[i++].climb(); } catch(ArrayIndexOutOfBoundsException e) { } 위의 예시는 아주 끔찍한 코드임. 무한 루프를 돌다가 배열의 끝에 도달해 ArrayIndexOutOfBoundsException이 발생하면 끝을 내는 것. 이 코드는 잘못된 추론을 근거로 성능을 높여보려 한 사례임. JVM은 배열에 접근할 때마다 경계를 넘지 않는지 검사하는데, 일반적인 반복문도 배열 경계에 도달하면 종료한다. → 따라서 이 검사를 반복문에도 명시하..

이펙티브 자바 - 9장. 일반적인 프로그래밍 원칙

9장 - 일반적인 프로그래밍 원칙 💡 지역변수의 범위를 최소화하라 “지역변수의 유효 범위를 최소로 줄이면 코드 가독성과 유지보수성이 높아지고 오류 가능성은 낮아진다” 1. 지역변수의 범위를 줄이는 방법 지역변수의 범위를 줄이는 가장 강력한 기법은 역시 ‘가장 처음 쓰일 때 선언하기’다. 사용하려면 멀었는데, 미리 선언부터 해두면 코드가 어수선해져 가독성이 떨어짐. 미리 선언해두면 변수를 실제로 사용하는 시점엔 타입과 초깃값이 기억나지 않을 수도 있음 → 거의 모든 지역변수는 선언과 동시에 초기화해야 한다. 메서드를 작게 유지하고 한 가지 기능에 집중하기 한 메서드에서 여러 가지 기능을 처리한다면 그중 한 기능과만 관련된 지역변수라도 다른 기능을 수행하는 코드에서 접근할 수 있을 것임. → 메서드를 기능별..

이펙티브 자바 - 8장. 메서드

8장 - 메서드 💡 매개변수가 유효한지 검사하라 “매개변수의 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사하자” 1. 매개변수 검사 매개변수 검사를 수행하지 않았을 때 문제점 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있음. 메서드가 잘 수행되지만 잘못된 결과를 반환할 수 있음 메서드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 수 있음. → 매개변수 검사에 실패하면 실패 원자성(failure atomicity)을 어기는 결과를 낳을 수 있음. 매개변수 검사는 메서드 몸체가 실행되기 전에 진행해야 함. 매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 함. 2. 단언..