경제적 자유를 이루고 싶은 개발자

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

인코딩

인코딩에 대해 가장 중요한 사실 한가지는 일반 텍스트란 개념은 존재하지 않다라는 것입니다.

우리가 보는 html 문서의 head태그 에서도 문자열인코딩의 규칙을 기재해줘야 하는 것이 있다.

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

우리가 사는 세계 에는 여러가지 언어들이 존재한다 

하지만 많은 소프트웨어 개발자가 문자집합, 인코딩, 유니코드와같은 신비로운 세계를 빨리 따라 잡지 못한다는거에 낙남을 한다고 한다. 우리가 많이 아는 아스키 코드는 문자 하나 담는 데이터사이즈는 2바이트 밖에 되지 않습니다.

그러나 우리가 아는 세계언어 는 문자하나에 2바이트를 담는게 불가능할수있다. 각자의 나라에서 쓰는 문자는 쓸수 있어도 중국의 언어가 들어있는 문자열을 한국에서 열어봤다고 치면 이 문자가 중국말인지 한국말인지 알수가 없다

한국에서 열어본 문자열은 그저 쓰레기 값이될수 밖에없다 그래서 한국말로 궯냟쒊꿜 같은 문자로 표현될수가있다.

그러면 우리는 어떻게 이문제를 해결 해야 하는가 이다 . 그 문제 해결은 이미 나와있다. UTF-8 유니코드이다

가변길이 문자열로 이문자열 안에는 이 문자열이 한국말로 되어있는지 영어로 되어있는지 중국어로 되어있는지 알수있는 구분 코드가 있다.

3장 조엘 테스트 : 더 다은 코드를 위한 12단계 2편

이 책에서 조엘은 더나은 코드를 위한 12단계를 설명했다.

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

6 . 일정을 업데이트 하고 있는지

개발 이 가장 중요한 요소라면 완료 시점을 파악하는것도 매우 중요하다 .

7. 명세서를 작성하고 있는지.

명세서를 작성하는 건 대다수 프로그래머들이 싫어하는 작업이다.

하지만 설계단계에서 문제를 발견하면 쉽게 몇줄만 수정할수있지만 

기능이 다 완성되고나서는 시간과 비용이 급격히 낭비가도니다 그리고 그코드를

작성한 프로그래머에게도 정신적 타격이 일어난다. 

그렇기에 코드를 작성하기전 살계 명세서를 하는것이 중요하다.

8. 조용한 작업 환경에서 일하고 있는지

지식 노동자에게 생산성을 극대화 할수있는 조용한 작업환경을 주는게 좋다

시끄러운 분위기에서 1분 집중력이 흟어지면 업무흐름이 끊겨 15분이라는 시간이 날라갈수가 있다.

9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있는지.

기본적인 업무의 최적화 되어있는 컴퓨터와 모니터 프로그램들이 있으면 생산성을 더욱 극대화할수있다.

모니터 한대로 사용자 인터페이스 코드를 디버깅하는 작업과 

모니터 두대로 디버깅하는 작업은 업무의 효율성부터 차이가난다.

화력이 떨어지는 도구를 사용하고 그 피로가 누적이 된다면 프로그래머는 비생상적으로 바뀔수있다.

10. 테스터를 별도로 두고 있는지 

프로그래머 2~3명마다 별도의 테스터를 두고 있는것이 오히려 비용낭비를 줄일수있다.

사람들이 테스트의 중요성을 모르고있다.

11. 프로그래머 채용 인터뷰때 코딩 테스트를 하는지.

오디션을 볼때 , 학교를 들어갈때 우리는 모두 시험에 쳐서 들어간다 

프로그래머도 마찬가지 여야 한다.

12.무작위 사용편의성 테스트를 수행하고 있는지.

지나가는 사람을 붙잡아 방금 작성한 코드를 하용해보는 기법입니다. 

이렇게 하면 사용편의성 문제를 약 95% 를 찾아낼수 있다.

무작위 사용편의성 테스트는 사용자 인터페이스를 점점 개선 할수있는 큰장점이 있다.

##3장 조엘 테스트 : 더 다은 코드를 위한 12단계 1편##

이 책에서 조엘은 더나은 코드를 위한 12단계를 설명했다.

1. 소스코드 관리시스템을 사용하고 있는지.

2. 한번에 빌드를 만들어낼 수 있는지

3. 일일 빌드를 하고 있는지

4. 버그 추적시스템을 운영하고 있는지

5. 코드를 새로 작성 하기 전에 버그를 수정하는지

6. 일정을 업데이트 하고 있는지

7. 명세서를 작성하고있는지

8. 조용한 작업 환경에서 일하고 있는지

9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있는지

10. 테스터를 별도로 두고 있는지

11. 프로그래머 채용 인터뷰 때 코딩 테스트를 하는지

12. 무작위 사용편의성 테스트를 수행하고 있는지

1. 소스코드 관리시스템을 사용하고 있는지.
   형상 관리 툴 CSV, SVN, GIT 은 좋은 프로그램이다. 프로그래머들이 많은 함께 일하려면 형상광리 툴 을 이용하는것이
   가장 효과적이라고 한다. 그리고 이러한 형상관리 툴을 이용한곳은 코드를 날렸다는 이야기를 들어본적이 없다고 한다.

2. 한번에 빌드를 만들어 낼수 있는지
   빌드를 만들기 위해 몇단계 거치는건 비효율적이라고 한다. 빌드 프로세스가 한번에 끝나지 않을경우 실수하기가 쉽다고 한다.

3. 일일 빌드를 하고있는지
   소스 코드를 관리할때 빌드가 깨진상태로 소스코드를 넣는 것과
   깨진걸 수정하였는데 코드 저장소에 업데이트를 안했을때 다른개발자들은 빌드 깨져 자기의 일을 할수없게 된다 .
   그래서 점심시간이나 퇴근하기전 업데이트는 습관화 가 되어있어야 한다.

4. 버그 추적시스템을 운영하고 있는지
   버그 관리 시스템을 사용하지않으면 품질이 나쁜 코드가 나올수 있다고 한다.
   버그가 1개정도일때는 기억하기 쉬우나 2개 이상의 버그가 생겼을때 프로그래머는 버그를 지억하기 쉽지않다고 한다.
   그래서 버그 추적 시스템을 잘활용 하고 버그 추적 소프트웨어가 복잡하다면 중요한 항목만 뽑아서 활용하기를 바란다.

5. 코드를 작성하기 전에 버그를 수정하는지.
   새로운 코드를 작성하기전 버그는 발견 즉시 수정을 해야한다 버그를 방치해두고 새로운 코드를 작성하고 시간이 흐른뒤
   우리는 그버그가 어떤 코드에서 일어났는지 까먹을 수가 있다. 출시한후에 버그가 발결됬다고 해보자 버그를
   찾으려고 많은 자본과 시간을 쏟아야한다.