ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 프로그래밍 이야기 - DRY 원칙을 지키고 있습니까?
    개발 2007.08.28 21:57

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

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

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

    수정 사항은 그리 복잡하지 않고 단순 노가다 성으로 한가지 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 블로거뉴스에서 이 포스트를 추천해주세요. [추천]

    댓글 11

    • 프로필사진

      좋은글이네요, 좀 더 생각하고 효율적인 프로그램을 만들고 싶지만, 막상 개발 일정에 맞추다 보면, 알면서도, copy&paste를 하기 마련인 것 같습니다.. 개발자들을 위해서라도, 이렇게 하면 안되는데 말이죠..^^

      2007.08.28 23:41
      • 프로필사진

        개발자 책임만도 아닐거예요. 늘 일이란게 시간이 촉박하게 다가오니까요.. 저희도 이번 개선때 좀더 근본적인 해결을 해야 하는데 시간이 없어서 중간만 하기로 했습니다. 다음번에 잊지 않고 작업해야 할텐데 윗선에서는 그런걸 잘 이해 못하는 부분이 있어서요.. 의견감사합니다. ^^;

        2007.08.29 08:03 신고
    • 프로필사진

      한국의 액티브x가 이토록 활성화된 것이 나중에 리눅스가 대세가 되었을 때 모두 뜯어고칠 일자리를 남겨두기 위해서...라는 썰도 있습니다. 그냥 썰이니까 심각하게 생각하시진 마시구요...;;;

      2007.08.29 07:18 신고
      • 프로필사진

        리눅스가 대세가 될리도 없어 보이고, 그정도로 까마득한 미래를 바라보고 개발할 만큼 여유 있는 회사도 없을거예요.^^;
        ~을 하기위해 라기 보다, 너무 근시안적으로 개발을 해 왔기 때문에 훗날 더 큰 문제가 생길지 몰랐거나, 무시하다보니 그렇게 된게 맞을거 같습니다. 리플 감사합니다. ^^;

        2007.08.29 08:12 신고
    • 프로필사진

      요즘들어 아키텍트의 중요성을 절실히 깨닿고 있는 중입니다..

      2007.08.29 10:29
      • 프로필사진

        저도 도움을 얻을 수 있도록 좀 더 구체적으로 말씀해 주시면 좋겠습니다 ^^;

        2007.08.29 12:33 신고
      • 프로필사진

        ㅎㅎㅎ 일하면서 정신없이 리플을 달다보니 뜬금없는 소리가 되버렸네요 ㅋㅋ 설계단계에서 모든걸 고려를 안하고 개발에 들어가면 나중에 고칠일이 엄청 많아진다는 소리였습니다 ^^;; 요즘 두개 제품의 설계와 개발을 동시에 하려니 힘드네요 ㅎㅎ 앞으로도 은글 많이 써주시기 부탁드립니다~ ps. 근데 DRY는 뭔가요?

        2007.08.29 13:36
      • 프로필사진

        2개 제품을 동시에 --;; 정말 머리 아프겠네요 .
        아무리 대단한 사람도 설계에 모든 경우의 수를 다 담을 수 있는 사람은 없을거 같습니다. 중간 중간에 요건이 변경되더라도 좀 더 쉽게 변경관리 할 수 있도록 개발하는 수 밖에 없을 것 같다는 생각이 듭니다.
        DRY - Don't Repeat Yourself 약자이구요.. 같은 지식을 반복해서 코딩하지 말라는 의미라네요^^; 바쁘신데 찾아 주시고 감사합니다.

        2007.08.29 13:48 신고
    • 프로필사진

      화타의 두 형들이 더 명의이지만 소문난건 화타 뿐이라는 얘기가 생각나는군요

      2009.04.15 22:15 신고
    • 프로필사진

      인터넷에서 퍼온 바에 의하면...

      중국의 전설적인 명의 화타에게는 형이 둘 있었다고 한다. 어느날 왕이 화타를 불러서 칭찬을 하였다고 한다.

      화타는 자기는 칭찬을 받을 자격이 없다고 하면서 왕에게 형 이야기를 들려주었다.

      "제 큰 형님은 세상에 가장 뛰어난 명의입니다. 병이 생기기 전에 미리 조절해주어서 형님은 사람이 병에 걸리지 않고 무병장수할 수 있게 해 줍니다.

      제 둘째 형님은 큰 형님만큼은 되지 않지만, 병이 조짐이 보이면 미리 알고 조절해 주어서 큰 병으로 발전하지 않게 해 줍니다.

      저는 그런 안목이 없기 때문에 사람이 큰 병에 걸린 후에 치료를 합니다. 그래서 큰 병에서 회복된 사람들이 저를대단한 줄 알지만, 사실 병을 미리 생기지 않도록 예방해 주고, 또 큰 병으로 발전하지 않도록 해 주는 형님들의 능력에 비하면 저는 새발의 피라고 할 수 있습니다."

      2009.04.15 23:56 신고
Designed by black7375.