요약본이다.

버그의 종류
1. 자료의 비정상적인 흐름을 통제하지 못해서 발생하는 버그
2. 논리의 정확하지 않은 정의에 의해 발생하는 버그
3. 프로그램의 외부의 요인(라이브러리, 운영체제, 아키텍쳐, 프레임워크)에 의해 발생하는 버그

또다른 버그의 종류 분류
1. 일관성이 없는 UI
2. 기대에 미치지 못하는 기능
3. 낮은 성능
4. 크래쉬 및 데이터 충돌

버그의 한예
STL의 자료구조에 대한 동기화 문제
-> 해결 뮤텍스를 이용하여 동기화 해결

쓰레드 사용 가이드 라인
1. 메인쓰레드로 충분한 처리가 가능하고 불가피한 이유가 없다면 불필요한 쓰레드를 만들어 구조를 복잡하게 만들지 마라.
2. 어떠한 자료구조이든 사용될 때 여러 쓰레드에 의해 이 자료구조가 접근될 수 있음을 항상 고려하라.
3. 불가피한 경우가 아니라면 여러 개의 쓰레드에서 동시에 접근 가능한 글로벌 변수와 스태틱 변수를 사용하지마라. 글로벌 변수와 스트택 변수를 사용시에는 개발 팀 전체의 코드 리뷰를 거쳐서 반드시 사용해야 하는 타당성을 입중해라.

커널오브젝트(뮤텍스, 이벤트, 세마포어)를 다룰때, 커널오브젝트의 이름 명명 규칙, 커널오브젝트의 시큐리티 속성을 조심스럽게 다루어야 한다. 제대로 짓지 않은 naming, 혹은 NULL값을 할당함으로서, 오류를 일으키지 않도록 해야 한다.

MSDN을 참조할때는 API의 설명외에도 Remarks와 Requirement를 반드시 확인해야 한다.
(용용 : API를 설계할때, 가장 중요한 점은 바로 이해하기 쉬운 문구를 써야 한다는 것이다. 글을 보고도 이해를 할 수 없다는 것은 가장 불쌍한 것이다. 특정 뛰어난 아키텍트의 api 설계 원칙에 의해서 설계되어도 다른 팀원들에게 이해되지 않는 문구로 설명해놓으면, 결국 잘못된 쓰임새로 인식하게 되고, 버그를 생성하게 되는 요인으로 작용하게 된다.
api를 설계할때는 충분하게 이해되기 쉬운 구어체가 쓰여야 하면, 적절한 예면, Remark, Requirement를 잘 기술해야 한다.
다른 팀원들에게도 쉬운 이해를 도울 수 있으며, 자신에게도 도움이 될 수 있다.)

실수를 줄이기 위한 개발 시스템, 조엘 테스트
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한번에 프로젝트의 빌드를 만들어 낼수 있습니까?
3. 일일 프로젝트 빌드(Daily Build)를 하고 있습니까?
4. 버그 추적 시스템을 운영하고 있습니까?
5. 코드를 새로 작성 전에 버그를 수정합니까?
6. 개발 일정을 지속적으로 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업환경에서 일하고 있습니까?
9. 돈이 허락하는 한도 내의 경제적인 범위애서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

거시적인 관점에서의 개발추
1. 연구/개발
2. 판매/마케팅
3. 고객지원

Posted by '김용환'
,