3장 더 나은 코드를 위한 12단계

조엘 테스트

1. 소스 코드 관리 시스템을 사용하는지?
2. 한방 빌드를 만들어낼 수 있나?
3. 일일 빌드를 수행 중인가?
4. 버그 추적 시스템 운영 중인가?
5. 코드를 새로 작성하기 전에 버그를 수정하는지?
6. 일정을 업데이트 하는지?
7. 명세서를 작성하고 있는지?
8. 조용한 작업 환경에서 일하고 있는지?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하는지?
10. 테스터를 별도로 두고 있는지?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 진행 하는지?
12. 무작위 사용 편의성 테스트를 수행 하는지?

• 예 아니오로 대답해 예는 1점씩 올리면 되는 간단한 테스트
• 10점 이하는 심각한 문제점이 있다는 의미.
• 대다수 2~3점으로 도움이 필요함.
• 마이크로소프트는 12점 만점

이 책을 읽었을때 해당 테스트를 진행 후에 업무를 위해 몇가지를 추가했었다. 그땐 2점 이었지만, 지금은 6점으로 점수가 오른것 같지만 여전히 도움이 필요한 수준이다.

버그 추적 시스템

효과 적인 버그 추적 시스템은 아래 항목을 포함해야 한다.

• 버그를 재현하기 위한 완벽한 단계
• 예상 수행 결과
• 관찰한 (버그로 간주되는) 실제 수행 결과
• 수정을 맡을 개발 책임자
• 수정 했는지 여부

명세 없이 코드는 없다.

4장 개발자가 꼭 알아둬야 할 유니코드와 문자 집합에 대한 고찰

• ASCII 7비트 제외 8비트 128~255 사이 공간은? 사용처에서 임의로 정했었음.
• 인터넷이 대중화 되면서 유니코드 또한 대중화

유니코드

• A -> 0100 0001 기존은 비트로 표현.

• 유니코드에서 글자 A는 관념적 이상, A, B는 다르고, a와도 다르다. 다만, 폰트가 각기 다른 A, A, A는 같다. [.. 표현 불가능.. 책 읽어보기 바람]

• 유니코드 컨소시엄은 각 알파벳에 존재하는 관념적인 철자마다 고유 번호를 붙여 놓았고, U+0645라는 식으로 표현.

• 이 고유 번호를 코드 포인트라고 부름.

• U+는 유니코드를 의미하며, 숫자는 16진수로 표현.

• U+0639는 아라비아 글자인 Ain을 나타냄.

• 영어 글자 A는 U+0041임.

• http://unicode.org에서 코드 포인트 확인 가능

• Hello는 유니코드 U+0048 U+0065 U+006C U+006C U+006F로 표현 가능.

인코딩

• 유니코드가 2바이트라는 미신을 이끌어낸 유니코드 인코딩에 대한 초기 아이디어는 단순히 코드 포인트 숫자 두개를 각각 바이트로 저장하자 였음.
• 따라서 Hello는 00 48 00 65 00 6C 00 6C 00 6F로 표현 가능
• 하지만, 48 00 65 00 6C 00 6C 00 6F 00은 어떤지?
• CPU 특징에 따라 리틀 엔디안이나 빅엔디안으로 저장 가능함.
• 유니코드 문자열 시작부분에 FE, FF를 저장하는 관례가 생김
• FE FF는 UTF-16/리틀 엔디안일 경우에만 해당하며, UTF-8에서는 EF BB BF를 UTF-32/리틀 엔디안에서는 FF FE 00 00을 사용
• `이를 유니코드 바이트 순서 표시라 부름

이상과 달리 현실에서는 모든 유니코드 문자열의 시작 부분에 바이트 순서를 표시하진 않음 … [??]

공간 낭비

• U+00FF 처럼 상위에 존재하는 사용하지 않는 코드 포인트의 공간 낭비를 해결하려 함

UTF-8의 등장

• UTF-8은 유니코드 코드 포인트를 따르는 문자열을 저장하기 위한 또 다른 시스템

• 8비트 바이트를 사용해서 매직 U+넘버를 기억 공간에 저장

• UTF-8은 0~127 사이에 존재하는 모든 코드 포인트를 단일 바이트로 저장함

• 128 이상 코드 포인트만 2, 3바이트에서 시작해 최대 한계인 6바이트 까지 확장 저장

위 표가 뜻하는 바를 완벽하게 이해하진 못하겠다.

2018-03-30, 변경! 최소와 최대는 범위를 뜻함 한글 “위” 코드 포인트는 U+C704로 00000800~0000FFFF 범위에 속함 따라서, 1110xxxx 10xxxxxx 10xxxxxx 형식을 사용하며, U+C704를 2진수로 변경시 1100 0111 0000 0100로 표현되고, 순서대로 형식에 맞게 넣어주면 된다. 따라서 한글 ==위==는 코드포인트 U+C704이고, 이는 UTF-8 2진수로 변환시 11101100 10011100 10000100 로 변환된다. 결과적으로 이 문자는 3바이트로 인코딩 된다.

결국 첫 128 문자는 1바이트로 표시되고 **(ASCII)**, 그 다음 1920 문자는 2바이트로 표시되며, 나머지 문자들 중 BMP 안에 들어 있는 것은 3바이트, 아닌 것은 4바이트로 표시된다.

아하!!!,, 더 자세한 내용은 위키 백과 참조!

• 이런 방식을 적용할 경우 UTF-8로 표현한 영어 텍스트가 ASCII와 완전히 똑같이 맞아 떨어짐 [????]

• U+0048 U+0065 U+006C U+006C U+006F Hello 문자를 UTF-8은 48 65 6C 6C 6F로 저장함.

• 이 방식은 ASCII, ANSI, 지구상에서 통용되는 모든 OEM 문자 집합으로 저장하는 방식과 동일.

허허.. 이해가 잘 안됨.. 왜케 이해가 안되는게 많지.. 문서좀 뒤벼 봐야될것 같다.

일반 텍스트 개념은 존재하지 않는다.

• 문자열은 인코딩 방식을 기록해야 한다.
• Content-Type: text/plain; charset=“UTF-8”

크하.. 다시 읽어도 제대로 이해되지 않는 부분이 많으니 정진 하도록…

Reference

• 조엘 온 소프트웨어