8장 - 프로그래밍 일반

지역 변수의 유효 범위를 최소화하기
1. 필요한 곳에서 변수를 선언하고 가급적 바로 초기화하는 것으로 코드를 이해하기 쉽게 만들 수 있다.
for 루프보다는 for-each 루프 사용 - 그러나 루프문이 중첩된다면 기존의 for이 버그 확률을 낮춰준다.
가급적 라이브러리를 사용하기.
정확한 계산에는 부동소숫점 변수는 쓰지 않기 - 부동소수점은 결과값이 부정확함
Wrapper 클래스보다는 기본형 변수를 쓰기 - 성능에 이점. == 등 비교 연산자를 쓸 때 실수할 여지를 줄여줌.
불필요하게 String클래스 사용하지 않기
1. int, boolean 등 가급적 적절한 데이터타입을 사용하기.
2. enum을 대신할 상수로 쓰지 않기.
3. 여러 데이터를 묶어서 하나의 String으로 사용하지 않기
문자열 결합의 성능 저하 주의 - 가급적 StringBuilder 사용하기. 근데 JDK 버전 1.6부터는 알아서 StringBuilder 쓰도록 바뀌었으므로 뭘 써도 무방할듯.
변수를 선언할 때는 concrete class보다는 interface로 선언하기
1. 좀 더 유연한 코드가 될 수 있음. 다만 concrete class로 선언하는 경우도 있는데 그건 그 클래스에만 존재하는 기능을 쓰려고 할 때.
2. 그리고 String 이나 BigInteger 같은 value class의 경우에도 그냥 class로 변수 선언
3. interface가 없다면 당연히 그냥 class로 선언하는 수 밖에 없다.
reflection 보다는 interface 사용하기
1. 리플렉션은 성능이 안 좋고 코드를 알아보기가 어려운 단점이 있다. -> 보통 초기화에만 사용하고 실제로 어플리케이션이 작동할 때는 리플렉션을 안 쓰는게 정상이다.
native method 분별력 있게 사용하기
1. VM 성능이 예상보다 좋으므로 단순히 성능이라는 이유만으로 native method를 사용하는 것에는 무리가 있다. 면밀하게 비교해보고 확실한 이득이 있을 때만 쓰는 것이 좋다.
2. native method는 자바의 여러 장점들을 손상시킨다. 메모리와 관련해서 안전하지 않게 되며, 이식성이 안 좋아지게 된다. 또한 디버깅도 아주 어려워진다. 그리고 native method로 진입하고 빠져나올 때 오버헤드가 존재한다.
잘 판단해서 최적화하기
1. 일반적으로 최적화는 하지 않는 것이 가장 훌륭한 방법이다. 얻는 것 보다 더 많이 잃기 쉽다.
2. 빠른 것 보다는 좋은 어플리케이션 작성에 노력해야 한다.
3. 설계를 할 때 성능에 제한이 생기지 않도록 노력해야 한다. 즉 가변형 타입을 만들어서 불필요하게 많은 객체를 생성하게 된다던가, 컴포지션이 적합한 곳에 상속을 쓴다던가, 인터페이스보다 concrete class로 변수를 선언하는 등의 부분이다. 나중에 갈아끼우기 힘들어진다.
4. 다만 좋은 성능을 얻겠다고 API를 뒤트는 것은 매우 나쁜 발상이다. API를 뒤틀지 않고 성능을 개선하는 방법이 나올 수 있고, 이런 경우 한번 뒤틀린 API를 다시 정상적으로 돌리는 것은 아주 힘들다.
5. 정 최적화를 하겠다면 하기 전과 후의 성능을 측정하자. 자바는 프로그래머가 짠 코드와 컴파일된 바이트코드간의 간격이 크다. 그렇기 때문에 최적화를 통해 실제로 성능이 개선되었는지 코드 시점에서 판단하기가 아주 어렵다.
6. 성능을 측정하고 나서 요구사항에 부합한다면 놔두고, 아니라면 프로파일러를 사용해서 문제의 근원을 파악해서 그 부분만을 최적화하는 것이 옳다.
보편화된 작명 규칙 따르기
1. 무조건 따를 필요는 없지만 그래도 가급적 따르는 편이 유리
2. 패키지 이름은 숫자와 소문자로 된 컴포넌트 이름을 마침표로 연결하여 계층식 구조로 짓기. 일반적으로 인터넷 도메인을 거꾸로 뒤집어서 맨 앞에 붙인다. 가급적 짧고 의미있는 약어를 쓰는 것이 유리하다.
3. 클래스와 인터페이스는 가능한 하나 이상의 단어로 사용하되 각 단어의 첫 글자만 대문자로 쓴다. 약어를 쓰는건 좋지만 나만 아는 약어는 최대한 덜 쓰는게 유리하다. 두문자어는 취향 대로.
4. 상수 필드는 모두 대문자로 하고 단어는 _으로 구분
5. 메소드, 필드, 지역 변수는 첫 글자를 소문자로 하고 각 단어는 대문자로 구분
6. 타입 매개 변수는 가능한한 단일 문자로 구성. 일반적으로 임의 타입은 T, 컬렉션의 요소는 E, Map의 키 값은 K, V, 예외는 X로 사용. T에 이어 U, V, T1, T2, T3 등으로 이어나가곤 한다.
7. 클래스는 보통 단일 명사나 명사구 사용
8. 인터페이스는 클래스와 비슷하거나 able, ible을 끝에 붙이는 경우가 많다
9. 메소드는 보통 동사나 동사구로 이름 짓는다. boolean 값을 반환하면 is, has 등으로 시작하는 경우가 많고 java bean 클래스라면 필드를 가져오는 메소드는 get으로 시작하고 설정하는 메소드는 set으로 시작하는 경우가 많다. 다만 타입을 변환하는 메소드는 to로 시작하는 경우가 많다.

Previous7장 - Method Next9장 - Exception

Last updated 7 years ago

8장 - 프로그래밍 일반

지역 변수의 유효 범위를 최소화하기
1. 필요한 곳에서 변수를 선언하고 가급적 바로 초기화하는 것으로 코드를 이해하기 쉽게 만들 수 있다.
for 루프보다는 for-each 루프 사용 - 그러나 루프문이 중첩된다면 기존의 for이 버그 확률을 낮춰준다.
가급적 라이브러리를 사용하기.
정확한 계산에는 부동소숫점 변수는 쓰지 않기 - 부동소수점은 결과값이 부정확함
Wrapper 클래스보다는 기본형 변수를 쓰기 - 성능에 이점. == 등 비교 연산자를 쓸 때 실수할 여지를 줄여줌.
불필요하게 String클래스 사용하지 않기
1. int, boolean 등 가급적 적절한 데이터타입을 사용하기.
2. enum을 대신할 상수로 쓰지 않기.
3. 여러 데이터를 묶어서 하나의 String으로 사용하지 않기
문자열 결합의 성능 저하 주의 - 가급적 StringBuilder 사용하기. 근데 JDK 버전 1.6부터는 알아서 StringBuilder 쓰도록 바뀌었으므로 뭘 써도 무방할듯.
변수를 선언할 때는 concrete class보다는 interface로 선언하기
1. 좀 더 유연한 코드가 될 수 있음. 다만 concrete class로 선언하는 경우도 있는데 그건 그 클래스에만 존재하는 기능을 쓰려고 할 때.
2. 그리고 String 이나 BigInteger 같은 value class의 경우에도 그냥 class로 변수 선언
3. interface가 없다면 당연히 그냥 class로 선언하는 수 밖에 없다.
reflection 보다는 interface 사용하기
1. 리플렉션은 성능이 안 좋고 코드를 알아보기가 어려운 단점이 있다. -> 보통 초기화에만 사용하고 실제로 어플리케이션이 작동할 때는 리플렉션을 안 쓰는게 정상이다.
native method 분별력 있게 사용하기
1. VM 성능이 예상보다 좋으므로 단순히 성능이라는 이유만으로 native method를 사용하는 것에는 무리가 있다. 면밀하게 비교해보고 확실한 이득이 있을 때만 쓰는 것이 좋다.
2. native method는 자바의 여러 장점들을 손상시킨다. 메모리와 관련해서 안전하지 않게 되며, 이식성이 안 좋아지게 된다. 또한 디버깅도 아주 어려워진다. 그리고 native method로 진입하고 빠져나올 때 오버헤드가 존재한다.
잘 판단해서 최적화하기
1. 일반적으로 최적화는 하지 않는 것이 가장 훌륭한 방법이다. 얻는 것 보다 더 많이 잃기 쉽다.
2. 빠른 것 보다는 좋은 어플리케이션 작성에 노력해야 한다.
3. 설계를 할 때 성능에 제한이 생기지 않도록 노력해야 한다. 즉 가변형 타입을 만들어서 불필요하게 많은 객체를 생성하게 된다던가, 컴포지션이 적합한 곳에 상속을 쓴다던가, 인터페이스보다 concrete class로 변수를 선언하는 등의 부분이다. 나중에 갈아끼우기 힘들어진다.
4. 다만 좋은 성능을 얻겠다고 API를 뒤트는 것은 매우 나쁜 발상이다. API를 뒤틀지 않고 성능을 개선하는 방법이 나올 수 있고, 이런 경우 한번 뒤틀린 API를 다시 정상적으로 돌리는 것은 아주 힘들다.
5. 정 최적화를 하겠다면 하기 전과 후의 성능을 측정하자. 자바는 프로그래머가 짠 코드와 컴파일된 바이트코드간의 간격이 크다. 그렇기 때문에 최적화를 통해 실제로 성능이 개선되었는지 코드 시점에서 판단하기가 아주 어렵다.
6. 성능을 측정하고 나서 요구사항에 부합한다면 놔두고, 아니라면 프로파일러를 사용해서 문제의 근원을 파악해서 그 부분만을 최적화하는 것이 옳다.
보편화된 작명 규칙 따르기
1. 무조건 따를 필요는 없지만 그래도 가급적 따르는 편이 유리
2. 패키지 이름은 숫자와 소문자로 된 컴포넌트 이름을 마침표로 연결하여 계층식 구조로 짓기. 일반적으로 인터넷 도메인을 거꾸로 뒤집어서 맨 앞에 붙인다. 가급적 짧고 의미있는 약어를 쓰는 것이 유리하다.
3. 클래스와 인터페이스는 가능한 하나 이상의 단어로 사용하되 각 단어의 첫 글자만 대문자로 쓴다. 약어를 쓰는건 좋지만 나만 아는 약어는 최대한 덜 쓰는게 유리하다. 두문자어는 취향 대로.
4. 상수 필드는 모두 대문자로 하고 단어는 _으로 구분
5. 메소드, 필드, 지역 변수는 첫 글자를 소문자로 하고 각 단어는 대문자로 구분
6. 타입 매개 변수는 가능한한 단일 문자로 구성. 일반적으로 임의 타입은 T, 컬렉션의 요소는 E, Map의 키 값은 K, V, 예외는 X로 사용. T에 이어 U, V, T1, T2, T3 등으로 이어나가곤 한다.
7. 클래스는 보통 단일 명사나 명사구 사용
8. 인터페이스는 클래스와 비슷하거나 able, ible을 끝에 붙이는 경우가 많다
9. 메소드는 보통 동사나 동사구로 이름 짓는다. boolean 값을 반환하면 is, has 등으로 시작하는 경우가 많고 java bean 클래스라면 필드를 가져오는 메소드는 get으로 시작하고 설정하는 메소드는 set으로 시작하는 경우가 많다. 다만 타입을 변환하는 메소드는 to로 시작하는 경우가 많다.

Previous7장 - Method Next9장 - Exception

Last updated 7 years ago