엘키의 주절 주절

http://filezilla-project.org/ 유명한 FTP 프로그램인 파일질라입니다. 서버, 클라이언트가 별도의 프로그램으로 제공 되고 있습니다. 소스도 함께 배포되고 있습니다.

* 멀티 쓰레드 시 동기화는 주의 깊게 하라 -> 멀티 쓰레드에서 같은 데이터를 동시에 접근하지 못하도록 동기화는 필수다. 현재 사용중인 데이터가 특정 시점까지 변해선 안 된다면, 데이터 사용이 끝나기 전까지 다른 쓰레드에서 접근이 불가능 하도록 해야 한다. * DB처리를 하러 간 사이에 벌어질 수 있는 일에 주의하라 -> DB처리를 위해 블럭이 되는 서버가 아니고선, DB처리를 하러 간 사이에는 간극이 존재한다. 이 때를 주의하자. 또, 서버가 여러 대인 경우, 다른 서버로 처리하러 떠난 상태까지 고려하도록 하자. * 돈은 signed 형을 사용한다. -> unsigned형을 쓰다 잘못해 언더플로우가 나는 것보다, 돈이 –가 되는 것이 낫다. * 검사 시점을 주의하라 -> 즉시 이뤄지는 처리가 아닌, ..

* strcpy 등의 길이제한이 없는 함수는 사용하지 않는다 -> strncpy, memcpy와 같은 함수를 사용하고, 스트링 맨 끝에, 0을 넣어주는 것이 안전하다. 특히나 클라이언트에서 올라온 데이터는 더더욱 그렇다. * 포인터 검사는 반드시 하라 -> 포인터 사용시에는 무조건 NULL포인터 검사를 하는 것이 좋다. 바로 쓰고 싶을 경우는 참조자를 사용해서 항상 유효한 데이터임을 알린다. * 서식 지정자에 넣는 값에 유의하라. -> 스트링 안에 %s %d 라는 코드가 있고, 가변 인자가 주어지지 않으면 에러가 발생한다. %s 로 문자열을 입력 받으려 하는데, float형이나, int형을 입력했을 때에도 C는 널을 만나기 전까지 데이터 읽는 것을 멈추지 않는다. 잘못된 메모리를 접근 문제는 언제나 조심..

패치시에 문제가 하나도 발생하지 않는다면 얼마나 좋겠냐만은... 패치 과정에서 실수가 생기는 경우가 많은 것이 사실이다. 패치 준비과정에서의 피로와, 수작업으로 인해 사소한 실수가 큰 파장을 일으키는 것이 현실. 주로 점검시에 발생하는 문제는 패치 준비가 제대로 되지 않아 생기는 문제가 많다. 다음은 실 서비스 적용시 문제를 덜 일으키기 위한 방법이다. * 테스트는 최대한 실 서버와 같은 환경에서 -> 가급적이면 서버는 테스트 코드나 테스트 데이터를 적게 사용해야 한다. QA와 같은 테스트는 가급적이면 실 서버와 같은 환경과 데이터로 하는 것이, 실 서버 패치 시에 생기는 문제를 줄일 수 있다. 점검시 실서버 QA의 경우 특히나 가급적이면 테스트 데이터를 사용하지 말자. 또한 환경 설정 파일 (cfg, ..

프로그램은 기본적으로 조건과 상황에 따른 판단과, 결정으로 이루어진다. 네트워크 프로그램은 클라이언트와 상호 작용하기 마련인데, 처음 서버 프로그램을 작성할 때 할 수 있는 실수는 클라이언트를 너무 쉽게 믿어버린 다는 것이다. 클라이언트가 이 약속을 안지키면 어떻게 할 것인가? 클라이언트에 버그가 있다면 어떻게 할 것인가? 정상적인 클라이언트를 이용하지 않는다면 어떻게 할 것인가?? 서버는 반드시 방어적으로 동작해야 한다. 클라이언트가 잘못된 요청을 하더라도, 서버는 그 요청을 무시하거나, 잘못된 요청이라는 것을 알려주는 것에 그쳐야지 서버에 예외 또는 버그가 발생해선 절대 안된다. 다음은 직접 경험했던 상황들의 예이다. 직접 작성한 코드와, 유지 보수하던 코드에서 발생한 문제가 뒤섞여있지만, 클라이언트..

프로그램을 작성하다보면 예기치 못한 문제에 봉착할 때가 많습니다. 그런 문제를 덜 겪기 위해 다양한 개발 방법론을 접해보았고, 시도해 보았습니다. 그 중에서도 조엘의 이야기는 특별했습니다. 능률을 높이기 위한 복잡한 절차대신, 마인드와 작은 행동으로 그것들을 대신했습니다. 방법론을 쉽사리 적용시키기 힘든 초보 프로그래머인 저에게도 조엘의 이야기는 쉽게 받아들이고, 쉽게 적용시킬수 있는 것들이었기에 더더욱 좋지 않았나 생각합니다. 무엇보다 조엘 테스트(http://elky.tistory.com/149)는 꼭 체크해보시기 바랍니다. 조엘 테스트 점수 높은 팀 치고 안좋은 팀이 없습니다. 또 일정 예측이란, 예측 자체에 부담을 가질 것이 아니라, 예측과 실제 소요시간과의 오차를 줄여가는 과정이라는 얘기도 아주..

내가 처음본 API서적은 국내에서 가장 유명(아닐지도 모르지만)한 김상형씨의 API 정복이었다. 물론 나역시도 만족했고, 현재도 WIN32 API 레퍼런스로 사용하고 있다. API란 Application Programming Interface라는것, 그리고 기본적인 프로그래밍에 필요한 함수 집합이라는것은 알고 있었지만, 다들 배워야 한다기에, 다들 알아야한다기에 접했을뿐 별다른 감흥은 없었고, 더 알고 싶지도 않았다. 컴퓨터 공학을 공부하다보니 운영체제란 과목이 있었지만, 설명이 부족해선지, 아니면 교재가 좋지 않아선지 별 흥미를 느끼지 못했고, 다른 과목보다 관심도가 낮았다. 프로그래밍을 하는데, 왜 운영체제가 필요한지는 의문이었었고, 윈도우 프로그래밍에 필요한 내용을 어느정도 선(멀티 태스크, 멀티 ..

웃기는 이야기일지 모르지만, 사실 나는 게임이 좋아서 프로그래밍을 시작했다. 게임을 만들고 싶은데, 그래픽(간단한 그림도 많이 못그리는 편이다)에는 너무 소질이 없었고, 기획이란 분야는 너무 막막한 상황이었기에, 선택한것이 프로그래밍이었다. 그러나 그 시작과는 달리, 갈수록 프로그래밍의 매력에 빠져들었고, 프로그램을 만든다는 그 자체를 즐기게 되었다. 나에게 주어진 문제를 해결했을때 오는 짜릿함? 내가 만든것이 컴퓨터안의 가상 세계(이 표현은 틀렸을지도 모른다. 왜냐면 컴퓨터안의 세계는 저자의 말대로 bit로 이루어진 현실에 존재하는 세계이기도 하니까)에서 나의 발상을 코드화해서 그것을 구동하였을때의 즐거움? 이런건 무엇과도 바꿀수없는것이었다. 그러나 그 즐거움을 잊을때가 많았다. 어떠한 프로젝트를 위해..