메서드가 던지는 모든 예외를 문서화하라 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바 독의 @throws 태그를 사용하여 정확히 문서화하자. 하지만 예외는 있는데 main은 오직 JVM만이 호출하므로 Exception을 던지도록 선언해도 괜찮다. 자바 언어가 요구하는 것은 아니지만 비검사 예외도 검사 예외처럼 정성껏 문서화해 ...

추상화 수준에 맞는 예외를 던져라 수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다. 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해 버릴 때 종종 일어나는 일이다. 이는 프로그래머를 당황하게 하는 데 그치지 않고, 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킨다. 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 튀...

표준 예외를 사용하라 표준 예외를 재사용하면 얻는 게 많다. 그중 최고는 우리의 API가 다른 사람이 익히고 사용하기 쉬워진다는 것이다. 우리 API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다는 장점도 크다. 마지막으로, 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다. Illegal...

필요 없는 검사 예외 사용은 피하라 검사 예외를 싫어하는 자바 프로그래머가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게끔 해준다. 하지만, 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다. 어...

자바는 문제 상황을 알리는 타입으로 검사 예외, 런타임 예외, 에러, 이렇게 세 가지를 제공한다.호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다

일반적으로 통용되는 명명 규칙을 따르라 패키지와 모듈 이름은 각 요소를 점(.)으로 구분하여 계층적으로 짓는다. 요소들은 모두 소문자 알파벳 혹은 숫자로 이뤄진다. 조직 바깥에서도 사용될 패키지라면 조직의 인터넷 도메인 이름을 역순으로 사용한다. 예외적으로 표준 라이브러리와 선택적 패키지들은 각각 java와 javax로 시작한다. 각 요소는 일반...

리플렉션보다는 인터페이스를 사용하라 리플렉션을 이용하면 컴파일 당시에 존재하지 않던 클래스도 이용할 수 있는데, 물론 단점이 있다. 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다. 리플렉션을 이용하면 코드가 지저분하고 장황해진다. 성능이 떨어진다. 리플렉션은 아주 제한된 형태로만 사용해야 그 단점을 피하고 이점만 취할 수 있다. 컴파일타...

관련 코드 바로가기개발을 시작한 지 얼마 되지 않았을 때 "내가 배치를 할 수 있었으면 기능이 더 풍성하였을 텐데.."하는 생각을 많이 하였던 것 같습니다.드디어 배치에 관해 공부하고 프로젝트에 맞도록 배치 관련 설정을 해보았는데 함께 살펴봅시다.@EnableBatch

객체는 인터페이스를 사용해 참조하라 적합한 인터페이스만 있다면 매개변수뿐만 아니라 반환 값, 변수, 필드를 전부 인터페이스 타입으로 선언하는 것이 좋다. 객체의 실제 클래스를 사용해야 할 상황은 '오직' 생성자로 생성할 때뿐이다. 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 더 유연해질 것이다. 나중에 구현 클래스를 교체하고자 하...

다른 타입이 적절하다면 문자열 사용을 피하라 문자열을 쓰지 않아야 할 사례 문자열은 다른 값 타입을 대신 하기에 적합하지 않다. 많은 사람이 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 대 주로 문자열을 사용한다. 입력받을 데이터가 진짜 문자열일 때만 그렇게 하는 게 좋다. 받은 데이터가 수치형이라면 int, float, BigIntege...

관련 코드 바로가기이번 프로젝트에서 시큐리티 관련 설정의 경우 이전에 함께하게 된 프로젝트에서 다른 분이 작성하신 설정을 레퍼런스로 하여 일부분을 Hiit 프로젝트에 맞도록 수정하여 사용하였습니다.그렇기에 "이번에는 이런 이유로 이렇게 설정했었구나?!"하는 느낌으로 가

관련 코드 바로가기"그냥 JPA가 해주는 거 잘 사용하면 되는 거 아니야?!"라고 할 수 있지만..ㅎㅎㅎ이번 프로젝트에서 Repository 계층을 설계하며 고민한 것들을 나누어 보려 합니다.사실 저는 BaseEntity에 대한 부정적인 시선을 가지고 있었습니다.자바에

관련 코드 바로가기프로젝트를 몇 번 진행하다 보니 비즈니스 로직에 관한 고민과 함께 가장 많이 한 고민이 프로젝트 아키텍처에 관한 것이었습니다.그렇기에 이번에는 본격적인 개발에 들어가기 전에 아키텍처에 대한 고민을 먼저 하였습니다.우선 가장 먼저 한 고민은 "어떤 모듈

박싱된 기본 타입보다는 기본 타입을 사용하라 오토박싱과 오토언박싱 덕분에 기본 타입과 참조 타입을 크게 구분하지 않고 사용할 수는 있지만, 그렇다고 차이가 사라지는 것은 아니다. 둘 사이에는 분명한 차이가 있다. 어떤 타입을 사용하는지는 상당히 중요하다. 주의해서 선택해야 한다. 기본 타입과 박싱된 타입의 주된 차이는 크게 세 가지다. 첫 번째...

전통적인 for 문 보다는 for-each 문을 사용하라 for 문을 사용할 때 필요한 건 원소들뿐이지만 필요하지 않은 반복지와 인덱스 변수가 생긴다. 이는 모두 코드를 지저분하게 할 뿐이다. 이렇게 요소 종류가 늘어나면 오류가 생길 가능성이 커진다. 그리고 for 문을 사용하면 컬렉션이냐 배열이냐에 따라 코드 형태가 달라진다. 이러한 문제는 f...

지역변수의 범위를 최소화하라 지역변수의 유효 범위를 최소로 줄이면 코드 가독성과 유지보수성이 높아지고 오류 가능성은 적어진다. 지역변수의 범위를 줄이는 가장 강력한 기법은 '가장 처음 쓰일 때 선언하기'다. 또한 거의 모든 지역변수는 선언과 동시에 초기화해야 한

관련 코드 바로가기스프링으로 백엔드 개발을 한다면 JPA는 대부분 사용하고 있으리라 생각합니다.이번 글에서는 Hiit 프로젝트에 JPA 관련 설정을 어떻게 하였는지 살펴봅시다.JPA 관련 설정 역시 스프링의 AutoConfiguration을 사용하지 않고 설정을 구현하

관련 코드 바로가기flyway는 데이터베이스의 형상 관리를 목적으로 사용하는 툴입니다.그리고 데이터베이스 스키마를 코드로 옮기는 기능을 제공합니다.아직 형상 관리에 대한 필요성은 느낀 경험은 없지만 스키마를 코드로 옮기는 기능을 제공하는 것은 큰 매력으로 다가왔습니다.

관련 코드 바로가기최근 현직자들이 포함된 팀에서 애플 로그인 기능을 담당하여 개발할 기회가 있었습니다. (해당 작업 PR)그렇기에 지금 작성하는 코드는 해당 프로젝트에서 많은 영향을 받고 있습니다.해당 개발을 하며 현직자분들과 이야기를 하며 느낀 것은 생각보다 개발에

프로젝트 기획을 하면서 개발자가 고민해야 하는 것은 핵심 기능을 사용자에게 전달하기 위해 고민할 것은 아래와 같다고 생각합니다.사용자에게 어떤 정보가 담기 화면을 보여줄 것인가?사용자에게 어떤 정보를 요구할 것인가?즉, 화면마다 어떤 Get, Post API가 필요한지