개발자의 자질과 프로젝트의 방향

대부분의 프로젝트는 개발자의 자질과 상당히 강한 의존성을 가지고 있다.
 
프로젝트는 초기 구축할 명확한 목표와 구축방법 및 적절한 용도를 위해 탄생한다.
이러한 프로젝트의 고유한 성격을 미리 계획하고 이에 적합한 개발자를 투입하는 것을 원칙으로 한다.
 
그러나 대부분의 프로젝트는 초기 목적과는 달리 개발자의 기술역량과 같은 자질에 구현 방법이
바뀌거나  우회하는 경우가 다반사이다.

이것은 단순한 기능적 요소 뿐만 아니라 비 기능적 요소의 변경도 초래하게 된다.
예를 들어, A 라는 개발자는 프로젝트에 필요한 기능을 구현하기 위한 자질이 충분하지 못할 경우
다음과 같은 오류를 범하기 쉽다.
 
1. 유사하게 기능은 구현하되 버그 발생률이 상당히 내재되어 있다.
    어찌어찌 하여 해당 기능을 꾸역꾸역 구현은 했고 한 두번의 테스트를 해 본 결과 잘 돌아가는 듯 하다.
    그러나 개인이 몇 번 테스트 할 때와 실제 환경에서 사용될 때는 그 환경이 확연히 달라 질 수있다.
    이에 대한 배려(?)를 하지 않으므로 결국 실제 환경에서는 버그 투성이의 기능이 되며
    결국 사용자는 해당 기능의 신뢰도가 완전히 사라져 쓸모없이 구색만 갖춘 기능이 되어 버린다.
  
2. 해당 기능과 유사한 기능으로 대체해 버리고 이를 클라이언트에게 설득한다
    해당 기능 보다는 유용하지 않지만 다른 방식으로 처리하도록 살짝 유도해 버린다.
    클라이언트는 '뭐 대충 돌아가지요' 하면서 받아 들이는 경우가 많다   
 
3. 기능요소를 뺄 수 있는지 (눈치껏) 확인 한 후 과감히 배제해 버린다
    자신이 사용하는 특정 언어에서 api 로 지원되지 않음을 확인 하고 구현이 불가능하다고 판단해 버린다.
    그리고 환경이 허락한다면 모르는 척 해당 기능을 배제해 버리거나, 최대한 늦추거나, 기술적으로
    구현하기 어려운 것이라 말해 버린다
 
 
물론, 제대로 관리되고 진행되는 프로세스 상의 프로젝트는 이러한 오류를 범하지 않을 것이다.
그러나 실제 현업에서는 이와 유사한 경우가 허다하다고 보여진다.
 
개발자는 자기 코드에 자존심을 걸어야 한다.
대충 API 에서 제공하는 것 이외에는 구현할 수 없다로 일관한다면 더 이상 개발자라 할 수 없다.
그냥 API User 일 뿐이다.
 
물론 방대한 API 를 잘 알고 적절히 선택할 수 있고 유용하게 응용할 수 있는 능력은 아주 중요하다.
중요한 것은 '그리고' 가 있어야 한다.
API 에 대한 지식과 응용력 그리고 창조적 개발이 그것이다
 
 
개발자의 자질때문에 프로젝트가 좌지우지 될게 아니라 프로젝트의 목적에 맞는 개발자를
투입하거나 필요한 교육을 통해 적합하도록 유도해야 할 것이다