버그(->재작성) 수정은 업무를 배우기 위한 수단인가?

요즘 각 멤버들이 각자가 버그를 수정하고 있다.

 

버그 수정의 내용을 보면 화면의 간단한 캡션을 변경한다던가

컨트롤을 이동한다던가 하는 그다지 프로그램에 전체적으로

영향력이 미치지 않는 범위에서 수정을 하는 것이 있다.

어찌 보면 이러한 것은 버그라기 보다는 사양 변경에 대한

재작성이라는 말이 옳을 것이다.

 

어쨌든 이렇게 영향력이 적은 것과 하나를 수정하면

줄줄이 물려 있는 코드들 때문에 전체 프로그램에 영향을

미치는 것들이 있다.

예를 들면 테이블의 레코드 추가, 플래그의 항목 추가 및 내용 변경등.

(이런 것들은 사양 변경에 따른 재작성이지

 버그가 아니다. 다시 한번 말하지만 버그 수정이 아닌 재작성이다.)

 

그리고 각 프로그램에 대해서 개발을 담당한 개발자들이 있다.

프로세스가 정립이 되지 않은 상태에서 다른 개발자들이

개발한 프로그램에 대해서 재작성을 하는 것은 과연

올바른 프로그램 수정인가? 나는 아니라고 생각한다.

이 경우에는 진짜 버그가 발생한다. 논리적인 버그가 대부분일 것이다.

 

그리고 버그 수정은 프로그램의 품질을 높이기 위한 하나의 수단이지

필수 사항은 아니다. 하지만 현재 프로젝트에서는 프로젝트 전반에 걸쳐

먼저 만들고 수정하기라는 생각이 전반에 팽배하게 깔려 있기 때문에

완벽한 요구사항 분석이 이루어 지지 않고, 그리고 그 상황에서

부족한 설계서, 이를 보고 개발한 개발자.

첫 단추가 잘못 끼워진 상태에서 옷을 입고 마지막에 끼워야할

단추 구멍이 없으니까 억지로 칼로 구멍을 내서 끼우고 있는 상황이다.

그러니 버그 수정이 수단이 아니라 마치 필수 사항인 것처럼 인식되고

개발자 윗선에서 인지 부족으로 발생한 부분을 마치 개발자가

인식이 부족해서 계속 버그가 발생하는 것처럼 생각을 하고 있으니

당연히 개발 공수는 늘어나게 되고, 버그는 계속 양산되며

겉잡을 수 없을 정도로 불안전한 프로세스 속에서 개발이 이루어

지고 있다.

 

재작업 혹은 잘못된 개발로 인해 발생한 버그에 대한 수정은

필수 사항이 아니며 재작업 및 버그가 발생하지 않도록

안정화된 프로세스를 만들어 가야 한다. 또한 재작업 및 버그수정은

업무를 알아가기 위한 방법이 아니라 프로그램의 품질은 높이기

위한 수단일 뿐이다.

 

업무에 대한 분석은 차후에 프로그램이 완성이 되고나서

차츰 분석을 해도 늦지 않기 때문이다.