"개발자의 길을 걷고자 하는 후배들에게" 라는 제목으로 글을 적고 싶었지만,,,

재정적 수입이 직결되는 실무 개발 경력이 2년을 겨우 채우고
'개발연구원'이라는 직책을 갖고 개발을 시작한지 겨우 6개월...

차마 '후배들에게'라는 말을 쓸 수 없기에 '이들에게'라는 표현으로 글을 적습니다.


개발자의 길은 그리 호락호락하지도 않고 IT 업계의 3D 업종으로 분류되기도 합니다.
그리고, 많은 사람들이 '개발자'라는 이름에서 'Coder'를 생각하기도 합니다.

하지만, 개발자는 설계, 구현, 검증을 담당하는 사람이며 그와 관련된 1차적인 책임을 갖는 사람입니다.

그렇다면 이러한 개발자의 길을 걷고자 하는 사람들이
기본적으로 갖어야하는 마인드가 무엇일까요?

그리고, 소위 '수퍼개발자'가 되기 위해서는 어떠한 소양과 능력을 갖춰야할까요?


물론, 저도 알지 못하는 질문입니다.
하지만, 지금까지 그리고 앞으로도 그 답을 찾기 위한 힌트들이 계속 쌓여갈 것입니다.

저는 이글에서 지금까지 제가 찾은 힌트들을 이야기하고자 합니다.



1.  기초체력을 길러라

기초체력... 밤샘이 많으니 스테미나를 기르라는 것이 아닙니다.
물론, 필요한 경우는 많습니다. 하지만, '절대' 는 아니라고 생각합니다.

저는 개발 지식에 대한 기초 체력을 이야기하는 것입니다. 

- a. 특정 개발 언어에 대해 잘 알고 있다  (특정 언어를 마스터 했다?)
- b. 자료구조와 컴퓨터구조를 잘 알고 있다

위 두가지 중 어떠한 것이 개발자에게 기초체력일까?


전자를 선택하였다면, 당신은 오래달리기를 할 수 없는 보디빌더를 당신의 미래상으로 생각하고 있는 것입니다.
후자를 선택하였다면, 당신은 볼륨 없는 몸매를 소유한 마라톤 선수를 당신의 미래상으로 생각하고 있는 것입니다.
(마라톤 선수들의 몸매를 비하하는 것이 아닙니다. 보디빌더에 비해 상대적으로 몸매에 볼륨이 없음을 의미합니다)

어떠한 것이 진정한 기초체력일까요?
물론, 선택은 개인의 몫이겠습니다.


2. 컴파일러를 신뢰하지 말라

컴파일러는 컴파일러 개발자에 의해 정해진 syntax를 정해진 틀 안에서 기계어로 번역하는 녀석입니다.
즉, 언제든지 버그를 갖을 수 있는 요소를 갖고 있습니다.

컴파일러의 버그로 인하여, 내가 작성한 코드에 의한 바이너리 역시 버그를 갖는다?

흔한 경우는 아니지만 실제 벌어지고 있는 일들입니다.

개인마다 차이가 있기는 하겠지만, 중요한 기능을 하는 코드, 시스템에 영향을 미칠 수 있는 코드...
이러한 코드들은 신뢰할 수 있는 버전의 컴파일러 2가지 이상에서 컴파일하고 테스트하기를 권합니다.


3. 변수 사용에 유의하라

변수 사용에 있어서 유의해야할 것은 많이 듣는 이야기이고 흔한 이야기입니다.
하지만, 많이 듣다보니 한쪽 귀로 듣고 한쪽 귀로 흘리는 이야기 중 하나이기도 합니다.

우선, 모든 변수는 초기화 후 사용하도록 합니다.

정수형과 실수형은 0으로
문자형과 스트링은 null string으로
포인터는 NULL 포인터로  

선언과 동시에 초기화하도록 합니다.

또한, 형변환에 유의합니다.

WinAPI 사용 중에도 어쩔 수 없이 형변환을 해야하는 경우가 존재합니다.
하지만, 그 것은 형 변환으로 발생될 수 있는 상황을 명확히 판단할 수 있는 경우로 한정되어야 합니다.


4. 상수 사용을 자제하라

일단 이 부분의 설명은 C/C++이 기준이 될 것 같습니다.

코드 상에 상수가 사용되는 경우가 있습니다.
물론, 상수가 반드시 필요한 경우도 있습니다.

코드 상에 상수가 삽입되는 것은 반드시 리팩토링을 거쳐 제거해야하는 항목이라고 할 수 있습니다.

그 것은 유지보수를 위한 것이 크지만,
상수만 놓고보면 어떠한 이유로 그 상수 값이 삽입된 것인지 알 수 없기 때문이기도 합니다.

그래서 사용하는 것이 상수 definition 이나  const 타입의 전역 변수입니다.
물론, 그 definition 이름이나 변수의 이름은 용도 등을 명확히 알 수 있는 것으로 정의하는 것이 필요합니다.

또한, 동일한 상수 값을 갖더라도 사용되는 이유가 틀리다면 재정의를 하더라도 다른 이름의 정의를 사용하도록 합니다.



5. 구조체와 공용체, 비트필드

개발을 하다보면 native 코드에서는 구조체를 상당히 많이 사용하게 됩니다.
그리고, 훌륭한 역할을 소화해내기도 합니다.

하지만, 많은 개발자들이 공용체와 비트필드에 대하여 막연히 알고 있을 뿐
사용해본 적은 없다고 이야기하는 경우를 보게 됩니다.

프로토콜을 기준으로 설명드려보겠습니다.

프로토콜의 기본 형태는 구조체로 모델링될 수 있습니다.
그리고, 비트필드를 이용해서 프로토콜 Flags 를  상태를 확인할 수 있습니다.

이 때, 프로토콜 Flags 부분은 공용체로 unsigned short와 16bits 비트필드로 이중 정의되어
동일한 값을 필요에 따라 선택하여 사용할 수 있게 됩니다.




-------------------------------------------------------
일단, 간단히 생각나는 것들을 정리해봤습니다.
써놓고 보니 너무 뻔한 이야기인 것 같군요 ;;