서버 프로그래밍시 주의점

* strcpy 등의 길이제한이 없는 함수는 사용하지 않는다

-> strncpy, memcpy와 같은 함수를 사용하고, 스트링 맨 끝에, 0을 넣어주는 것이 안전하다. 특히나 클라이언트에서 올라온 데이터는 더더욱 그렇다.

 

* 포인터 검사는 반드시 하라

-> 포인터 사용시에는 무조건 NULL포인터 검사를 하는 것이 좋다. 바로 쓰고 싶을 경우는 레퍼런스를 사용해서 항상 유효한 데이터임을 알린다.

 

* 로그는 규격을 정해서 만들자

-> 로그는 분석이 필요하기 때문에, 로그 분석기를 적용하기 쉽도록 규격을 정해서 만들자.

 

* 서식 지정자에 넣는 값에 유의하라.

-> 스트링 안에 %s %d 라는 코드가 있고, 가변 인자가 주어지지 않으면 에러가 발생한다.
%s 로 문자열을 입력 받으려 하는데, float형이나, int형을 입력했을 때에도 C는 널을 만나기 전까지 데이터 읽는 것을 멈추지 않는다. 잘못된 메모리를 접근 문제는 언제나 조심하자

 

* 돈은 signed 형을 사용한다.

-> unsigned 형을 썼다가 자칫 뺄셈을 잘못할 경우 몇 십억이 되는 돈이 들어 갈수가 있다.

 

* 클라이언트에서 받은 값은 유효한 값인지 검사 한다.

-> 어떤 값이 들어올지 모른다. 신용은 금물!

 

* 아이템 장착 해제 시에는, 해당 아이템이 장착 중인지를 반드시 검사한다!

-> 클라이언트가 중복 착용/해제 시도를 안 할거라는 확신을 하지 말아라. 확신은 서버에서 직접 검사를 한 후에 해라.

 

* 검사 시점을 주의하라

-> 즉시 이뤄지는 처리가 아닌, 다른 곳에서 인증이나 처리를 하고 온 후 처리 되는 경우라면, 민감해야 한다.

다른 곳으로 처리를 하러 간 도중에, 이 값을 어떤 식으로든 사용하게 된다면, 오류가 생기기 때문이다.

 

* 테스트는 최대한 실 서버와 같은 환경에서

-> 가급적이면 서버는 테스트 코드를 적게 돌려야 한다. QA와 같은 테스트는 실 서버와 같은 환경에서 이뤄져야 실 서버 패치 후, 또는 실 서버 패치 시에 생기는 문제를 방지할 수 있다. 또한 환경 파일 (cfg, ini를 비롯한 데이터 파일)의 무결성 검사도 반드시 하도록 하자.

 

* 추가 하는 코드에 대해 명확히 이해하라

-> 코드를 추가할 때, 그 코드가 어떤 기능을 하는지 간단한 테스트라도 해라. 처음 시도, 사용하는 알고리즘이나 라이브러리 사용시에는 특히 주의하라. 그 기능을 명확히 이해하지 못하고 사용한다면, 그 것은 우연에 맡기는 프로그래밍을 하는 것이다.

 

* 적은 조건을 만족해도 잘 돌아가는 코드를 작성해라 (복잡도를 줄여라)

-> 많은 조건을 충족 해야 하는 상황에서만 잘 돌아가는 코드보다는, 적은 조건을 만족하는 상황에서도 잘 돌아가는 코드가 좋은 코드다. 특별한 이유(속도 향상, 메모리 제약 등)가 없다면 유연한 코드를 작성해라.

 

* 가정을 하지 마라. 코드에서 직접 제약을 걸어라.

-> 어떤 처리에 대한 클라이언트와의 규약 (예를 들면, 비번 방 지정은 방장만 할 수 있다던가, 게임 방에서만 가능하다던가 하는 가정)은 반드시 지켜질 수 있도록 코드에서 그 동작이 불가능 하도록 만들어라.

* 재귀적인 동작을 조심해라

재귀적으로 돌다 스택 오버 플로우가 나는 상황이나, 처리 과정이 맞물리다 재귀적으로 처리가 이뤄져 사용하는 메모리를 잃어 버리는 경우를 조심하라. 재귀로 인한 스택 오버 플로우는 말 할 필요도 없고, 재귀적으로 처리가 이뤄지다가 클래스 안이나, 힙에 잡힌 메모리의 주소를 사용하는 경우 프로그램의 비정상 동작이 원인이 될 수 있다. 혹시나 재귀적으로 돌아갈 여지가 생긴 경우에는 반드시 지역 변수로 선언해서 스택에 할당한 메모리를 사용하라.

 

* 멀티 쓰레드 시 동기화는 주의 깊게 하라

멀티 쓰레드에서 같은 데이터를 동시에 접근하지 못하도록 동기화는 필수다. 이 작업은 수작업이 덜 필요하도록 상위 단에서 작업 하는 것이 중요하다.

 

* 시간차에 주의하라

DB처리가 실 시간이 아닌 경우에는, (큐에 담아두었다 처리 하는 경우) 시간차가 있다. 이 시간차에 주의하자. 또, 서버가 여러 대인 경우, 다른 서버로 처리하러 떠난 상태까지 고려하도록 하자.

* 포인터를 담는 자료구조에서, 해당 자료를 빼고, 포인터에 동작할당 된 주소를 delete할 때 주의하라

한 곳에서 new한 데이터를, 여러 곳에서 사용할 때 주의하라. new한 객체의 delete는 가급적 한 곳에서만 하라. delete된 포인터를 자료구조에서 들고 있으면 dangerous 포인터가 되니 조심하자.

* 코드 재 사용시 가정이 깨지는 것에 주의하라

같은 코드를 다른 곳에서 재 사용시에 기존에 수립한 가정을 다시 검토하라.

* 배열 접근 시에는 무조건 범위 검사를 하라

배열 접근 인덱스는 반드시 유효한 값인지 범위 검사를 하라. 가급적이면 배열 접근 인덱스는 unsigned 한 값으로 사용해서, 배열 검사를 한번에 끝내는 것이 좋다.

* 자료구조에서 넣는 키 값과, 빼는 키 값에 주의하라.

온라인 서버 게임에서 호환을 위해 대소문자 캐릭터 아이디를 모두 메모리에 들고 있는 경우가 있다. 이 때 자료구조에 소문자 캐릭터 아이디로 넣고, 대문자 캐릭터 아이디로 빼는 경우문제가 생겼다. 주의 하자.

* 로그를 실서버, 개발 서버에 따라 다르게 동작시키자.
QA및, 개발 서버 때 찍을 로그와 실 서버에서도 찍을 로그를 구분하고, 쉽게 변경 가능하도록 하자. (개발자 명령어 등을 통해서, 서버가 러닝중인 상태에서도 해당 변수 플래그를 바꿔 로그를 찍거나 찍지 않도록 만들자)

 

* 증명을 하자
프로그래머는 추론이 아닌 증명을 해야 한다. 특정 상황이 의심스럽다면 그 상황이 맞는지 입증해라.

* 성급한 일반화의 오류를 범하지 말자
특정 플랫폼, 특정 컴파일러, 특정 라이브러리의 구현이 일반적이라고 믿는 일반화의 오류를 범하지 말자. 구현은 천차만별이다.

* 실 서비스에 적용할 바이너리에 대한 점검은 신중히 하자.

실 서비스에 적용될 변동 사항은 한번 더 생각하고, 한번 더 테스트해보자. 그리고, 일어날 수 있는 파급효과를 꼼꼼히 따져보자.

* DB스키마, 쿼리는 반드시 튜닝하자

쿼리 프로파일러 등을 통해서 DB 부하를 측정하라. 쿼리 자체가 느리다면, 쿼리 호출 횟수가 작아도 문제가 생길 수 있다.

* DB 접근 횟수를 조절하자
서버가 크리티컬한 이유에 DB는 절대 빠지지 않는다. DB는 데이터 저장소로써 매우 중요한 의미를 가지는데, DB 테이블 설계와, 쿼리로 인한 파급효과를 예측하는 것은 여러모로 중요하다. 하지만, DB에서 아무리 쿼리 튜닝, 스키마 최적화를 한다 해도, 코드에서 지나치게 많은 쿼리 호출, 비정상적으로 많은 데이터 삽입 등을 해서, 데이터 량 자체가 많다면 그 효과를 보기 힘들 것이다. DB사용량에 대한 코드에서의 최적화가 최 우선적으로 이루어지도록 하자.

출처 : http://blog.naver.com/elky84/10013134784