개발자 칠거지악

IT 전문 매거진에 실린 '개발자가 저지르기 쉬운 7가지 나쁜 습관'의 내용이다.

오늘자 전자신문에 실린 '정보통신산업진흥원 SW공학센터장(이상은)'의 컬럼 내용을 옮겨온다.

 

자칫 나태해지기 쉬운 개발업무를 돌아볼만 하다.

 

 

1. 욕심에 의한 엔지니어링의 남용

- 책에서 제시된 방식들이 항상 효과가 좋은 것은 아니어서 원래 사용했던 방법을 효과적으로 사용하는 것이 더 좋은 방법일 수 있다. 프로그래밍의 대가들은 "새로운 기법을 활용하는 것보다 더 중요한 것은 기능의 효과적 구현이다"라고 말하고 있다.

 

2. 계속 기능만 추가하고 개발했던 내용을 리팩토링하지 않는 것

- 이미 개발된 코드는 완전하지도 않으며 추가되는 기능이 점점 늘어 갈수록 복잡해지고 뒤엉켜 버리기 때문에 기존 코드의 품질과 유지보수성을 평가해 코드에 대한 신뢰성을 확보하는 것이 중요하다.

 

3. 개발자 사이의 경쟁

- 팀 간에 프로젝트가 비공개적으로 진행되면 다른 팀이 이미 구현한 라이브러리를 중복적으로 개발하게 된다. 개발의 최우선 과제 중 하나는 각자가 어떤 작업을 하고 있는지 서로에게 알리는 것이고, 모든 팀들이 공통의 목표를 갖고 정보를 공유하는 것이다.

 

4. 입력값의 유효성 검증에 실패하는 나태함

- 개발하면서 사소한 실수는 빈번히 일어자지만 잘못된 입력값을 받아들이는 개발 실수는 매우 치명적이어서 신중해야 한다.

 

5. 소스코드에 코멘트를 달지 않는 것

- 일단 개발된 소스코드는 보관되었다가 나중에 유지보수를 위해 다른 사람이 작업을 하게 되는 것이 보통이다. 이때 코멘트가 없다면 해당 코드가 무엇을 의미하는지 이해하기 어렵고 시간도 오래 걸린다. 따라서 최소한 힌트를 남겨둬야 한다.

 

6. 버전관리를 하지 않는 것

- 요즘엔 강력하고도 효과적인 버전관리 도구를 무료로 손쉽게 구할 수 있다. 심지어 분산 프로젝트를 관리할 정도의 도구도 최소 비용으로 구할 수 있다. 따라서 다른 문제가 없다면 가장 기본이 되는 버전관리시스템은 반드시 만들어둬야 한다.

 

7. 단위테스트를 하지 않는 것

- 개발된 프로그램이 좋은 평가를 받는 것은 개발자로서 영광스러운 일이다. 하지만 결함을 가진 코드가 출시된다면 그 뒤처리를 감당하기 어렵게 된다. 코드를 출시하기 전에 단위 테스트를 철저히 할수록 나중에 감당해야 하는 피해를 최소화할 수 있다.