프로그래밍 이야기 - DRY 원칙을 지키고 있습니까?

지난주 금요일 거래소에서 제도 변경관련 공문이 왔습니다.

증권회사이다 보니 시일에 맞게 제도변경을 해서 고객에게 완벽한 프로그램을 적용시키는 것이 제가 가진 숙제인데요.

이번 변경건과 관련 프로그램 변경범위를 파악하는 작업을 오전부터 하게 되었습니다.

수정 사항은 그리 복잡하지 않고 단순 노가다 성으로 한가지 TYPE 이 세분화 되어 4가지 TYPE 으로 처리되어야 하는 게 다였습니다.

언제나처럼 수정해야 할 범위를 찾아 Visual Studio .NET 2005에서 Find in Files 를 10여분 돌리고 분석해 본 결과 약 10개 정도의 모듈에서 20여 개 이상의 소스를 수정해야 한다는 걸 알았습니다.

문제는, 10여 개 모듈에 동일한 지식이 고스란히 복사되어 존재한다는 것입니다.

누군가 최초 코드를 만든 사람은 이 지식이 많은 곳에서 사용될 운명임을 몰랐을 것입니다.. 그러다 1년이나 2년 후 같은 지식이 필요했던 다른 개발자가 그 코드를 Copy & Paste 해서 자기 소스에 쑤셔 넣었겠죠. 한번 유리창이 깨지자 결국 모든 유리창이 다 깨지듯(깨진 창문 이론) 그 다음에는 더 많은 개발자가 너나 할 것 없이 똑 같은 짓을 반복하다 보니 이 지경이 되었습니다. (아..저희 개발팀이 만드는 프로그램이 다 엉망이라는 소리는 절대 아닙니다 ^^)

 

더 아이러니 한 것은 첫 번째 만들어진 소스는 계속된 제도 변경에 따라 코드가 수정, 발전되어 왔는데 나머지 복제품들은 전혀 수정되지 않았거나 일부만 수정되고 완전하게 변경된 사항을 담고 있지 않다는 것입니다.

프로그램 내에 동일한 지식을 여기 저기 흩어져 놓는 문제는 정말 심각합니다.

아무래도 네이버 블로그에 있는 “내 블로그에 퍼가기” 기능은 저희 개발팀의 코드 복사하기를 보고 만든 게 분명합니다. 특허라도 취해서 돈이라도 받아야 할까요 ^^;

 

제가 정말 좋아하는 책인 “실용주의 프로그래머” 에 다음과 같은 명언이 있습니다.

 

문제는 명세와 프로세스 그리고 프로그램을 개발하는 중에 지식을 중복해 넣기 쉽다는 것이다. 그렇게 된다면 애플리케이션이 선적되기 한참 전부터 유지보수의 악몽이 시작될 것이다.

실용주의 프로그래머 P66

 

오전 내내 여기 저기 흩어져 있던 지식들의 진화 과정을 분석하고, 어떤 식으로 지식을 중복되지 않고 한 곳에 가둘 수 있는지 고민한 다음 오후에는 간단한 공통함수를 통해서만 해당 지식을 접근할 수 있도록 캡슐화하고, 이를 개발자에게 공지했습니다. (저희 파트는 네이버 카페에 개발용 카페를 만들고 여기서 주요 변경사항을 주고 받는 방법을 사용합니다.)

물론, 이렇게 공통모듈화 하더라도 기존 프로그램을 죄다 새로운 방식으로 수정해야 하는 모험이 필요합니다.

한번 잘못 발을 담그면 유지보수 비용은 증가하기 마련이죠.

 

그러다가 또 이런 생각도 해 봤습니다.

저희가 모두 코딩에 대한 전문가적 지식으로 똘똘 뭉쳐 모든 지식을 관리하고, 계약에 의한 프로그램을 하고, 테스트 주도 프로그램을 철저히 따르고, 리팩토링을 주기적으로 실시하는 팀이었다면, 지금 인원 중 앞으로 몇 명 정도가 살아 남을 수 있을 까 하는 생각인데요

 

아직 제대로 이해하지 못해 마지막 장을 넘기지 못한 “익스트림 프로그래밍” 책에도 다음과 같은 공감 가는 얘기가 있습니다.

 

XP 팀은 일을 훌륭하게 하고, 추가 스트레스나 추가 시간 없이도 원래 요구 받은 것보다 더 많은 기능을 제 시간에 배치하는데 결함 수는 아주 적다. 다른 팀은 밤샘 작업을 하고, 마지막 순간에 범위를 난폭하게 축소하고, 결함이 눈보라처럼 흩날리는 가운데 제품을 배치한다. 그러나 조직이 다운사이징할 때 해고되는 팀은 XP팀이다. 그 까닭은 다른 팀이 더 ‘헌신’ 한 듯 해 보였기 때문이다. XP 팀의 작업 방식은 남다르기 때문에, 사회적으로나 정치적으로 부정적인 모양으로 눈에 띄기 싶다. XP 팀은 조직 전체의 목표를 달성하기 위한 자신들의 헌신을 강조하고, 이 작업 방식이 그 목표를 이루는데 어떻게 기여하는지 보여줄 필요가 있다.

익스트림 프로그래밍 P200

 

그렇습니다.

사실 누군가 엎질러 놓은 수많은 잘못을 바로 잡기 위해 더 많은 인원이 필요로 하고, 지금과 같은 조직구성원이 같이 일할 수 있는 게 아닌가 하는 생각도 듭니다.

역설적으로, 더 잘못 코딩 할수록 더 많은 개발자가 일자리를 마련할 수 있지 않나 하는 생각 ^^;;

 

PM 위치에 있고 보면 파트 내 인원 수 관리도 많이 신경 쓰이는 편이라 이런 쓸 데 없는 생각도 하게 되나 봅니다.

아무튼 요.. 오늘 얘기의 주제로 다시 돌아와서 절대로,, 공통적으로 사용될 지식은 흩트려 놓아서는 안 된다는 말씀을 드리고 싶습니다.

 

 

Daum 블로거뉴스에서 이 포스트를 추천해주세요. [추천]