▒ 개발자가 빠지기 쉬운 “나쁜 습관 6가지” ▒

▒  개발자가 빠지기 쉬운 “나쁜 습관 6가지” ▒

Tony Patton (TechRepublic) : 원문보기

 

Tony Patton 이 기고한 글을 ZDNET 에서 번역한 자료이다. 우리는 이 기사에 대한 내용을 우리의 시각에서 정리해 보았다. 이 글은 자유로이 읽고, 배포할 수 있다. 그러나 출처에 대한 공개를 해주는 좋은 습관이 필요하다.

 

아는 것은 싸움의 절반에 해당한다. 내가 하는 실수를 제대로 알고 있다면, 고치는 것은 시간 문제다. 초보와 베테랑 개발자 모두 전체 프로젝트의 진척에 방해가 될 수 있는 업무의 측면에 대해서 잘 못 알고 있는 경우들이 많다. 범하기 쉬운 실수들을 왜 미리 살펴 보아야 하는지 알아본다.

 

초보, 중급 개발자들과 함께 일해 왔는데, 베테랑 개발자를 포함해 모든 개발자들이 주의하지 않는다면 쉽게 빠질 수 있는 오해의 함정들을 몇 가지 발견하게 되었다. 여기에는 적절한 도구의 선택부터 웹 서비스의 적절한 사용법에 이르기까지 다양한 아이디어가 포함된다.

 

개발자들이 갖기 쉬운 6가지 오해에 대해서 설명한다.

 

1. .NET Application 개발을 위해서는 Visual Studio .NET 이 필수다. ?

 

이런 생각을 했다면, 버려라. MS .NET 개발을 처음 접해 본 사람들은 .NET Framework를 이용한 Application 개발을 위해서 Visual Studio .NET 이 꼭 필요하다는 오해를 하기 쉽다. 이는 사실이 아니다. 단지 MS Web Site에서 .NET Framework을 무료로 다운로드 받기만 하면 된다.

 

.NET Framework를 설치한 후 좋아하는 텍스트 편집기와 커맨드-라인 .NET Tool을 사용하면 된다. 또한 이미 나와 있는 SharpDevelop 과 같은 3^rd Party 개발 도구를 사용해도 된다. (현재 시점에 많은 제품들이 상용/오픈으로 나와 있다)

 

Visual Studio .NET의 대안에 관한 보다 자세한 논의를 담은 이전 기사를 참고하면 좋다. 개발도구의 선택은 개인적인 취향에 달려있지만 많은 개발 팀은 협업을 단순화하기 위해서 도구를 표준화 한다.

 

<의견>

좋은 의견이다. 충분히 검토할 가치가 있으며 이러한 논지는 개발이 벤더에 종속되지 않는 의미를 가지기도 한다. 그러나 점점 Visual Studio .NET을 벗어나서는 지원되지 않는 장점이 많아지는 것이 문제일 것이다. 이러한 것도 역시 개발에 꼭 필요한 부분이 아닐 수 있기 때문에 판단은 역시 당사자들이 하여야 할 문제일 것이다. 이제 11월 22일에 Visual Studio .NET 2005가 발표된다. 역시 많은 기능과 개발과 디자인을 연결하는 기능이 시도되고 있다. 이런 것들을 어떻게 적응할 것인가가 더 중요한 부분이 아닐까 한다.

 

2. 내가 습득한 정보, 꼭꼭 숨기기

개발자들이 갖는 독특한 특징의 하나는 정보를 모으는 것이다. 타인이 모르는 것에 대해 알 수 있는 능력은 종종 중요성에 대한 잘못된 인식을 키우게 된다. 반대로 이런 정보를 공유하게 되면 그룹 전체의 지식이 확대되므로 팀에 도움이 된다. 또한 공유된 개념은 다른 팀 멤버의 의견에 따라 발전할 수도 있다. 이 것은 오픈소스 운동의 핵심 측면이기도 하다. 마지막으로 다른 개발자나 개발자들에게 어떤 개념이나 아이디어를 설명하게 되면 많은 경우 당신의 지식도 커진다.

팀워크는 애질 소프트웨어 개발(Agile Software Development)와 같은 운동에 있어서 추진력이 된다. 또한 많은 그룹이 동료가 작성한 코드를 리뷰하고 조언을 주고 있다. 이런 행위는 양측이 서로 배우고 이해를 넓히는 역할을 한다.

3. 코드에서 코멘트 빠뜨리기

코드에 코멘트를 하는 것은 쉬우면서도 단순한 절차이다. 그렇다면 왜 코멘트가 자주 간과되고 무시되는가? 일부 개발자들은 어떤 형태로든 문서화를 하지 않는다면 일자리를 유지하는데 도움이 된다고 생각한다. 이는 바로 전에 다룬 정보 공유에 관한 오류와 밀접한 관계가 있다.

몇 군데 잘 배치된 코멘트는 코드의 판독성과 관리성을 향상시킨다. 그런데 코멘트가 남용될 수도 있다. 기본적으로 코드의 목적, 변수, 메쏘드 등을 짧게 설명하는 코멘트가 있으면 된다. 많은 그룹들은 코드에 변화가 생기면 코멘트를 삽입하기를 원한다. 이는 문제가 생겼을 때 변화의 내용을 파악하기 쉽게 한다.

4. 버전 컨트롤 시스템의 가치를 간과하는 것

많은 개발자들이 다음과 같은 시나리오를 너무나 잘 알고 있다. 중요한 웹 애플리케이션의 새 버전을 내놓았다. 그런데 웹 사이트의 문제점을 항의하는 전화가 다음날 아침부터 줄지어 날아든다.

개발자가 한두 가지 실수를 범했다는 것을 수용할 용의가 있다면, 버전 컨트롤 시스템은 이런 상황에서 최고의 친구가 될 수 있다. CVS, IBM 래쇼날 클리어케이스, MS 비주얼 소스세이프와 같은 버전 컨트롤 시스템을 사용함으로써 기존 버전의 애플리케이션으로 쉽게 돌아가서 이를 기반으로 제품을 생산할 수 있다. 이는 제품 사이트가 가동되는 것과 병행해 개발 환경 내에서 문제를 찾는데 필요한 시간을 벌 수 있도록 해준다. 이는 문제를 찾기 위해 제품 코드를 미친 듯이 찾는 것을 방지한다.

또한 소스 컨트롤 시스템은 병행 개발을 가능하게 하므로 팀 멤버들이 동일한 코드를 작성할 수 있다. 개발자들이 시스템에 변경된 사항을 입력하면 이들 변경사항이 한꺼번에 통합된다.

일부 개발자들이 버전 컨트롤 시스템을 싫어하는 한 가지 이유는 개발 절차에 있어서 하나의 계층을 추가하기 때문이다. 소스 컨트롤 시스템에 코드를 제출하고 추출하는 것이 시간을 잡아먹을 수 있다. 이런 시간이 일부 개발자들의 인내심을 시험할 수 있다.

5. 웹 서비스가 모든 프로젝트에서 필요하다는 생각

웹 서비스에 대한 모든 감언이설 때문인지 많은 개발자들은 프로젝트를 시작하면서 어떤 형태로든 웹 서비스를 사용해야겠다고 생각한다. 웹 서비스가 필요하거나 적절한 방법일 수는 있지만 무조건 써야 되는 것은 아니다. 상황을 분석해 웹 서비스의 구현이 적절한지 검토할 필요가 있다. 예를 들어 원격화와 같은 기술이 보다 적절할 수도 있다.

6. 데이터 확인의 중요성을 자주 잊는 것

데이터는 애플리케이션에서 다양한 방식으로 처리되고 조작된다. 이런 이유 때문에 개발자들은 데이터의 무결성과 유효성을 개발과정에서 확인해야 된다. 데이터는 널 문자를 리턴할 수 있는 백엔드 데이터베이스로부터 읽혀질 수도 있다. 널 문자는 대부분의 경우 예외상황 (exception)을 발생시키므로 실행을 계속하기 전에 데이터는 검사돼야 한다.

당신이 초보 개발자이거나 베테랑 개발자이거나에 상관없이 개발자들이 여섯까지 오해에 빠지기 쉽다는 것을 잘 알아야 한다. 심지어 이런 나쁜 습관에 당신이 빠지지 않는다고 해도 다른 팀원들이 이들 함정에 빠질 수 있다. 잠재적 실수에 대해 경각심을 가진다면 팀 프로젝트를 방해할 수 있는 실수들을 방지하는데 도움이 될 것이다.