Java로 프로그래밍할 때 피해야 할 9가지 실수

Java 는 세계에서 확고한 위치를 차지하고 있는 인기 언어입니다. 소프트웨어 개발. 강력하고 다재다능한 프로그래밍 언어입니다. 전 세계 약 30억 대의 디바이스에서 실행되는 Java 따라서 이를 사용할 때 최소 30억 건의 실수가 발생했습니다. 이 글에서는 더 이상 실수하지 않는 방법에 대해 집중해 보겠습니다.

1. 동시 수정 예외 가져오기

이것이 제가 겪은 가장 흔한 실수입니다. 경력 초창기에는 저도 여러 번 실수를 저질렀습니다. 이 실수는 컬렉션을 반복하는 동안 컬렉션을 수정하려고 할 때 발생합니다. 컬렉션의 동시 수정 예외 는 여러 스레드로 작업할 때도 발생할 수 있지만 지금은 기본 시나리오에 집중해 보겠습니다.

다음과 같이 가정합니다. 컬렉션 사용자 중 일부는 성인이고 일부는 그렇지 않은 사용자로 구성됩니다. 여러분의 임무는 어린이를 걸러내는 것입니다.

for (사용자 : 사용자) {

   if (!user.isAdult()) {

       users.remove(user);

   }

}

앞서 언급한 코드 는 결국 동시 수정 예외. 어디가 잘못되었을까요? 반복을 완료하기 전에 일부 요소를 제거하려고 했습니다. 이것이 바로 예외를 유발하는 요소입니다.

어떻게 피할 수 있나요?

이 경우 도움이 될 수 있는 몇 가지 방법이 있습니다. 가장 먼저 다음을 활용하세요. Java 8의 장점 스트림.

List adults = users.stream()

       .filter(User::isAdult)

       .toList();

사용 술어 필터를 사용하면 이전 조건의 반대를 수행했으므로 이제 포함할 요소를 결정합니다. 이러한 접근 방식의 장점은 제거 후 다른 함수를 쉽게 연결할 수 있다는 것입니다. 지도. 하지만 제발 다음과 같은 행동은 하지 마세요:

users.stream()

       .filter(v -> !v.isAdult())

       .forEach(users::remove);

또한 동시 수정 예외 스트림 소스를 수정하고 있기 때문입니다. 또한 디버깅하기 쉽지 않은 예외가 더 많이 발생할 수도 있습니다.

해결 방법 동시 수정 예외 단일 스레드 시나리오에서 직접 사용하도록 전환할 수도 있습니다. 이터레이터 및 그 remove() 메서드를 사용하거나 반복하는 동안 요소를 제거하지 않을 수 있습니다. 하지만 제가 추천하는 방법은 스트림 - 2022년입니다.

2. 비밀번호를 문자열로 저장하기

사이버 보안에 점점 더 많이 관여하게 되면서 적어도 한 가지를 언급하지 않는다면 제 자신에게 진실하지 않을 것입니다. 자바 실수 보안 문제로 이어질 수 있습니다. 사용자로부터 받은 비밀번호를 문자열 객체는 정확히 두려워해야 할 대상입니다.

의 문제점(또는 장점)은 다음과 같습니다. 문자열 는 불변이라는 것입니다. 사이버 보안 세계에서는 한 번 생성한 가치를 지울 수 없기 때문에 잠재적인 위협이 될 수 있습니다. 문자열 객체에 저장합니다. 컴퓨터 메모리에 액세스한 공격자는 일반 텍스트 비밀번호를 찾을 수 있습니다.

둘째, 문자열의 Java 는 JVM에 의해 인턴되어 PermGen 공간 또는 힙 공간에 저장됩니다. 생성할 때 문자열 객체를 호출하면 캐시되고 가비지 수집기가 작업을 시작할 때만 제거됩니다. 가비지 수집기는 비결정적 방식으로 작동하므로 언제 비밀번호가 문자열 풀에서 삭제되는지 확인할 수 없습니다.

어떻게 피할 수 있나요?

권장되는 접근 방식은 다음을 사용하는 것입니다. char[] 또는 비밀번호를 다음과 같이 저장하는 것을 지원하는 라이브러리를 사용하면 더 좋습니다. char[]예를 들어Password4j. . char[] 배열은 변경 가능하며 초기화 후 수정할 수 있습니다. 비밀번호를 처리한 후에는 비밀번호를 처리한 후 char[] 암호 배열에 임의의 문자를 기록합니다. 공격자가 컴퓨터 메모리에 액세스할 수 있는 경우 사용자의 비밀번호와 관련이 없는 임의의 값만 볼 수 있습니다.

3. (언)처리 예외

초보자는 물론 고급 프로그래머도 예외를 올바르게 처리하는 방법을 모릅니다. 이 문제에서 그들의 가장 큰 죄는 예외를 무시하는 것입니다. 결코 좋은 접근 방식이 아닙니다.

안타깝게도 모든 상황에 맞는 완벽한 솔루션을 제공할 수는 없습니다. 예외의 시나리오를 접하게 됩니다. 각각의 경우에 대해 개별적으로 생각해야 합니다. 하지만 해당 주제에 대해 시작하는 방법에 대한 몇 가지 조언을 드릴 수 있습니다.

어떻게 피할 수 있나요?

1. 무시 예외를 사용하는 것은 결코 좋은 습관이 아닙니다. 예외는 어떤 이유로 던져지므로 무시해서는 안 됩니다.

2. try {...} catch(Exception e) { log(e); } 에 대한 올바른 접근 방식은 거의 없습니다. 예외 처리합니다.

3. 다시 던지기 예외를 사용하여 사용자에게 오류 대화 상자를 표시하거나 최소한 로그에 포괄적인 메시지를 추가할 수 있습니다.

4. 예외를 처리하지 않고 방치했다면(처리해서는 안 되지만) 댓글에 최소한 설명을 남겨 주세요.

4. 널 사용

안타깝게도 경우에 따라 반환하는 Java 함수를 찾는 것은 매우 일반적입니다. null. 문제는 이러한 함수는 클라이언트가 결과에 대해 널 검사를 수행하도록 강제한다는 것입니다. 이 함수가 없으면 널포인터 예외 가 던져집니다.

다른 하나는 null 가치. 왜 그런 생각을 했나요? 이 경우 함수는 널 검사를 수행해야 합니다. 타사 라이브러리를 사용하는 경우 함수의 내부를 변경할 수 없습니다. 그럼 어떻게 해야 하나요?

더 중요한 것은 코드를 읽고 합격한 것을 확인한 다른 개발자들입니다. null 기능을 구현하는 데 왜 이런 기괴한 방법을 선택했는지 의아해할 것입니다.

어떻게 피할 수 있나요?

반환하지 마십시오. null 가치! 절대! 함수가 어떤 유형의 컬렉션를 반환하면 빈 컬렉션. 단일 객체를 처리하는 경우 널 객체 디자인 패턴을 사용할 수 있습니다. 이후 Java 8로 구현됩니다. 선택 사항. 그 외에는 가장 권장되지 않는 접근 방식은 예외.

5. 무거운 문자열 연결

가장 인기 있는(혹은 피즈버즈 다음으로 인기 있는) 면접 질문이기 때문에 실수하지 않으셨으면 좋겠습니다. 지금쯤이면 알고 계시겠지만 문자열 객체는 Java - 일단 생성되면 수정할 수 없습니다. 따라서 문자열 리터럴은 불필요한 메모리 할당을 의미합니다. 연결 문자열 객체를 만들 때마다 임시 문자열 빌더 객체로 변환하고 다시 문자열로 변경합니다. 따라서 이 솔루션은 많은 수의 문자를 결합하려는 경우 절대 적합하지 않습니다.

어떻게 피할 수 있나요?

이 문제를 해결하려면 문자열 빌더. 쉽게 조작할 수 있는 변경 가능한 객체를 생성합니다. 물론 언제든지 문자열 버퍼 만약 프로젝트 는 동시 컨텍스트에서 사용됩니다.

6. 기존 솔루션 미사용

소프트웨어를 개발할 때 작성하는 언어의 기본을 아는 것은 필수이지만 그것만으로는 충분하지 않습니다. 새로운 기능을 구현하는 과정에서 마주치는 많은 알고리즘 문제는 이미 다른 사람이 해결한 경우가 많습니다. 보안 알고리즘을 처음부터 다시 구현하는 경우를 너무 많이 보았습니다. 이러한 접근 방식은 오류가 발생하기 쉽습니다. 한 사람이 이렇게 복잡한 솔루션을 철저하게 테스트할 수는 없습니다. 보안 알고리즘에 대한 집단적 지식은 팀 중급 프로그래머로 구성된 팀이 한 명의 천재 프로그래머의 위대함보다 더 나은 경우가 거의 대부분입니다. Java 개발자. 기존 솔루션을 필요에 맞게 조정하기만 하면 되므로 새로 개발할 필요가 없습니다.

어떻게 피할 수 있나요?

작업 중인 문제를 해결하는 라이브러리를 검색해 보세요. 비슷한 솔루션을 찾아보세요. 웹에서 사용할 수 있는 많은 라이브러리는 무료이며 숙련된 개발자와 전체 Java 커뮤니티가 다듬고 테스트한 것입니다. 이러한 라이브러리를 사용하는 것을 두려워하지 마세요.

7. 테스트 작성에 충분한 시간을 확보하지 못함

코드가 항상 완벽하게 실행될 것이라고 믿고 싶을 때가 있습니다. 코드에 대한 테스트를 작성하지 않는 것은 다음과 같은 최악의 죄악입니다. Java 소프트웨어 개발자. 많은 사람들이 단위 테스트 대신 수동 및 탐색 테스트를 선호하는데, 이는 말도 안 되는 소리입니다. 프로젝트에 버그가 없는 세계 최고의 코드를 제공하는 데 집중할 수 있는데 왜 테스트 작성에 시간을 낭비하나요? &ltjoke>. 현실은 잔인하고 테스트를 작성하지 않고는 고품질의 코드를 제공할 수 없다는 것이 밝혀졌습니다.

어떻게 피할 수 있나요?

항상 코드에 대한 테스트를 준비해야 합니다. TDD 접근 방식이 유지 관리가 쉽지 않다는 것을 알고 있지만 최소한 코드가 실행될 수 있는 모든 조건을 포괄하는 테스트를 제공해야 합니다. 여기에는 예외적인 상황에 대한 테스트도 포함됩니다. 단위 테스트는 필수입니다. 코드가 리팩터링하기 쉽고 향후 개발에서 확장 가능한지 확인하려면 프로젝트의 모든 기능에 대해 단위 테스트를 제공해야 합니다. 

한 가지 더. 테스트 코드의 높은 표준을 유지하세요 - 그만한 가치가 있을 것입니다. 밥 삼촌의 조언에 전적으로 동의합니다.

또한 다른 유형의 테스트도 잊지 마세요. 통합 테스트는 모든 프로젝트에서 고려해야 할 사항입니다.

8. 액세스 수정자 잊어버리기

사적인 것과 공적인 것, 맞죠? 어떻게 잊을 수 있을까요? 알고 보니 더 많았습니다. 처음 학습을 시작했을 때 Java를 통해 보호된 액세스 수정자에 대해 확실히 배웠을 것입니다. 경우에 따라 유용할 수 있으므로 그 존재에 대해 알아두는 것이 좋습니다.

Java 개발자 패키지 범위를 잊어버리는 경우가 많습니다. 패키지 범위는 암시적이기 때문에 사용 사실을 기억하지 못하기 쉽습니다. Java 키워드. 패키지 범위가 중요합니다. 이를 통해 보호된 메서드를 테스트할 수 있습니다. 패키지가 동일하다면 테스트 클래스 경로에서 보호된 항목에 액세스할 수 있습니다.

어떻게 피할 수 있나요?

보호된 수정자에 대해 기억하고 패키지 범위를 통해 테스트할 수 있습니다.

9. Spring 대신 순수 JavaEE 사용

학습 후 다음 단계 Java SE는 실행 방법을 배우는 것입니다. Java 서버에서 엔터프라이즈급 애플리케이션을 만드는 방법을 알아보세요.

초보자는 JavaEE에 대한 튜토리얼이 너무 많아서 학습의 함정에 빠지는 경우가 많습니다. 심지어 'Thinking in Java'라는 Java 프로그래머' 바이블에는 JavaEE에 대한 언급만 있고 다른 옵션에 대해서는 언급이 없습니다.

어떻게 피할 수 있나요?

JavaEE는 과거의 노래입니다. 요즘에는 Spring이 대세이며 Java EE는 그저 있으면 좋은 존재입니다. 모든 최신 엔터프라이즈급 애플리케이션은 Spring을 사용하므로 다음과 같은 학습을 강력히 고려해야 합니다. 여기.

자세히 읽어보세요:

최고의 Java 개발자를 찾는 올바른 방법

Java를 위한 최고의 프로젝트 유형

핀테크 기업을 위한 최고의 프로그래밍 언어