백엔드/Java86 Effective Java 맛보기 11탄 직렬화 자바 직렬화의 대안을 찾으라 직렬화는 위험하니 피해야 한다. 시스템을 밑바닥부터 설계한다면 JSON이나 프로토콜 버퍼와 같은 대안을 사용하자. 신뢰할 수 없는 데이터는 역직렬화하지 말자. 꼭 해야 한다면 객체 역직렬화 필터링을 사용하되, 이마저도 모든 공격을 막아줄 수는 없음을 기억하자. 클래스가 직렬화를 지원하도록 만들지 말고, 꼭 그렇게 만들어야 한다면 정말 신경써서 작성해야 한다. Serializable을 구현할지는 신중히 결정하라 Serializable은 구현한다고 선언하기는 아주 쉽지만, 그것은 눈속임일 뿐이다. 한 클래스의 여러 버전이 상호작용할 일이 없고 서버가 신뢰할 수 없는 데이터에 노출될 가능성이 없는 등, 보호된 환경에서만 쓰일 클래스가 아니라면 Serializable구현은 아.. 2019. 9. 21. Effective Java 맛보기 10탄 동시성 공유중인 가변 데이터는 동기화해 사용하라 여러 스레드가 가변 데이터를 공유한다면 그 데이터를 읽고 쓰는 동작은 반드시 동기화 해야 한다. 동기화하지 않으면 한 스레드가 수행한 변경을 다른 스레드가 보지 못할 수도 있다. 공유되는 가변 데이터를 동기화하는 데 실패하면 응답 불가 상태에 빠지거나 안전 실패로 이어질 수 있다. 이는 디버깅 난이도가 가장 높은 문제에 속한다. 간헐적이거나 특정 타이밍에만 발생할 수도 있고, VM에 따라 현상이 달라지기도 한다. 베타적 실행은 필요 없고 스레드끼리의 통신만 필요하다면 volatile한정자만으로 동기화할 수 있다. 다만 올바로 사용하기가 까다롭다. 과동한 동기화는 피하라 교착상태와 데이터 훼손을 피하려면 동기화 영역 안에서 외계인 메서드를 절대 호출하지 말자.. 2019. 9. 21. Effective Java 맛보기 9탄 예외 예외는 진짜 예외 상황에만 사용하라 예외는 예외 상황에서 쓸 의도로 설계 되었다. 정상적인 제어 흐름에서 사용해서는 안되며, 이를 프로그래머에게 강요하는 API를 만들어서도 안된다. 복구할 수 있는 상황에서는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자. 확실 하지 않다면 비검사 예외를 던지자. 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지도 말자. 검사 예외라면 복구에 필요한 정보를 알려주는 메서스도 제공하자. 필요 없는 검사 예외 사용은 피하라 꼭 필요한 곳에만 사용한다면 검사 예외는 프로그램의 안정성을 높여주지만, 남용하면 쓰기 고통스러운 API를 낳는다. API 호출자가 예외 상.. 2019. 9. 21. Effective Java 맛보기 8탄 일반적인 프로그래밍 원칙 지역변수의 범위를 최소화하라 전통적인 for 문보다는 for-each문을 사용하라 전통적인 for 문과 비교했을 때 for-each문은 명료하고, 유연하고, 버그를 예방해 준다. 성능 저하도 없다. 가능한 모든 곳에서 for문이 아닌 for-each 문을 사용하자. 라이브러리를 익히고 사용하라 바퀴를 다시 발명하지 말자. 아주 특별한 나만의 기능이 아니라면 누군가 이미 라이브러리 형태로 구현해놓았을 가능성이 크다. 그런 라이브러리가 있다면, 쓰면 된다. 있는지 잘 모르겠다면 찾아보라. 일반적으로 라이브러리의 코드는 여러분이 직접 작성한 것 보다 품질이 좋고, 점차 개선될 가능성이 크다. 여러분의 실력을 폄하하는 게 아니다. 코드 품질에도 규모의 경제가 적용된다. 즉, 라이브러리 .. 2019. 9. 21. Effective Java 맛보기 7탄 메서드 매개변수가 유효한지 검사하라 메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다. 이런 습관을 반드시 기르도록 하자. 그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다. 적시에 방어적 복사본을 만들라 클래스가 클라이언트로부터 받는 혹은 클라이언트로 반환하는 구성요소가 가변이라면 그 요소는 반드시 방어적으로 복사해야 한다. 복사 비용이 너무 크거나 클라이언트가 그 요소를 잘못 수정할 일이 없음을 신뢰한다면 방어적 복사를 수행하는 대신 해당 구성요소를 수정했을 때의 책임이 클라이언트에 있음을 문서에 명시하도록 하자0. 메서드 시그너처를 신중히 설계하라 다중정의는 신중히 .. 2019. 9. 20. 이전 1 ··· 10 11 12 13 14 15 16 ··· 18 다음 728x90