2009년 7월 31일 금요일

Copy & Paste의 종말


직업상 다른 개발자들이 작성해 놓은 코드를 볼 기회가 정말 많습니다.

그러다보면 자주 접하는 것이 복사된 코드들입니다. 

소소코드 Copy & Paste는 개발자의 대단히 큰 잘못입니다. 즉, 소스코드를 복사해 놓는 것은 쉽지만 그로 인해서 지속적으로 회사와 후배들이 부담을 져야 하기 때문입니다. 즉, 회사의 생산성을 갉아 먹는 행동입니다. 그런 개발자는 해고가 되어야 마땅하지요.

한쪽 제품이나 컴포넌트에서 사용한 함수나 소스코드들을 복사해 와서 다른 제품이나 컴포넌트에서 사용하는 것입니다. 동일하게 그대로 사용하는 경우도 있고, 약간 수정해서 사용하는 경우도 있습니다.

이런 일이 반복되다보면 비슷한 코드들이 회사의 전체 소스코드 중에서 여기 저기 산재하게 됩니다. 그러다가 버그가 발생하는 그중 일부는 고쳐지고, 일부는 여전히 버그를 가지고 있습니다. 또 해당 기능이 변경이 될 때도 이를 모두 찾아서 변경하기란 쉬운 일이 아닙니다. 이쯤 되면 개발은 창의적인 작업이 아닌 점점 노동이 되어 갑니다.

이런 공통적인 소스코드들은 공통모듈을 잘 계획해서 공통적으로 사용할 수 있어야 합니다. 공통모듈은 전사적으로 관리가 되어서 효율적으로 사용할 수 있도록 해야 하며, Copy & Paste의 욕구가 생겨도 시간을 약간 더 들여서 공통모듈화 하는 노력을 들이는 것이 필요합니다.

공통모듈을 관리하려면 당연히 소스코드관리시스템을 잘 사용해야 하고, 각 제품이나 컴포넌트들이 공통모듈들과 더불어 효과적으로 빌드가 가능하도록 빌드 스크립트도 준비가 되어야 합니다.

Peer review, code review가 정착되어서 다른 팀에서 서로 모르고 중복된 작업을 하는 것을 줄여야 합니다.

또, 특정 고객을 위한 커스트마이즈된 제품을 만들 때 대규모 소스코드 복사가 일어나는데, 이를 통제없이 만들고 방치하면 함수 몇개 복사한 것과는 비교도 안되는 큰 비용을 치뤄야 합니다. 물론 상황에 따라서 다르기는 하지만, 이런 경우에는 가능하면 소스코드 브랜치를 줄이고 브랜치를 만들더라도 소스코드관리시스템을 이용하여 잘 관리를 해야 합니다. 그리고 추후 Merge를 통해서 브랜치의 수명 주기를 짧게 가져갈 필요가 있습니다.

여기저기 복사된 쌍둥이 소스코드들... 참 문제가 아닐 수 없습니다.

댓글 13개:

  1. 제가 생각하는 copy&paste의 문제는 이해부족에서 온다고 생각합니다.

    체계적으로, 기존에 다른 사람이 작성한 코드를 분석하지 못했기때문에,
    (이유는 여러가지가 있겠죠? 실력부족, 문서화안됨, 스파게티코드, 시간부족 등)
    기존에 잘 돌던코드는 그대로 두고 플러스 알파만 내가 했다... 뭐 이런거 아닐까요?

    또 비슷한 측면에서,
    자신이 작업하던 코드의 경우에도, 설계가 세밀하게 진행되지 않은 상태에서,
    일단 만들어보면서 얼기설기 작업해나가다 보면,
    적절한 타이밍에 리팩토링 시기를 놓쳐버린 상태가 되는 경우가 있습니다.

    시간비용 + 귀차니즘 때문에, Copy&Paste로 떡칠이 되기 시작하는 거죠.


    마지막으로는 코딩스타일에서 올 수 있겠네요.
    현재 제가 주로 작업하는 분야가 C언어를 사용한 임베디드 분야 (wipi등)쪽 인데,
    판단문과 분기문이 수도 없이 떡칠되기 시작하면서, 소스가 주렁주렁 ㅎㅎㅎ

    state머신이나 적절한(펑션포인터등 사용) 분기체계가 아닌,
    switch-case, if-else 등으로 관성이 붙어버리는 거죠.

    이상태에서 상용으로 소스는 릴리즈나가고 -_-;;;;;
    대형 리팩토링 했다가는(이것도 안습) 되던 소스도 망가지고,
    고객사에서는 최대한 손대지 말고 요거 하나만 고쳐달라고 하죠.

    저희는 견디다 못해서....
    고객사에서 version 2 만들자고 할때, 그쪽 목적은 기능개선, UI개편이었는데,
    저희내부에서 아키텍처 부터 다시 잡아서 첨부터 다시 만들었습니다.

    후우... 그나마 이제는 좀 살만해졌네요.

    며칠전부터, 이 블로그를 처음부터 정주행하고 있는데,
    오늘 정주행 완료하고 나니까, 현실적으로 와 닿는 얘기들이 왜이리 많은지요 ㅠㅠ

    계속 분발해야겠습니다.

    현실적 고민이 뭍어나오는 좋은 글들 감사합니다.

    p.s. 3일에 걸쳐 블로그글을 다 읽고 났더니.. 진작에 신경쓸걸 하는 울컥한 마음에, 댓글이 횡설수설 합니다. 양해부탁드립니다.

    답글삭제
  2. 제가 최근 일독한 소프트웨어 공학에 대한 좋은 블로그에서 (http://allofsoftware.net) Copy & Paste의 종말 이라는 글을 읽고, 여러가지 생각들이 떠올랐습니다. 제가 남긴 댓글은 아래와 같습니다. http://allofsoftware.net/77#comment610946 제가 생각하는 copy&paste의 문제는 이해부족에서 온다고 생각합니다. 체계적으로, 기존에 다른 사람이 작성한 코드를 분석하지 못했기때문에, (이유는..

    답글삭제
  3. 확실히 와닿네요!! 고객사별로 소스가 따로 노는데 그 소스 통채로 복사해와서 붙여넣고 다른 고객사 나갈 때 커스터마이징한 소스도 그대로 붙어서 나가지요~ 보고 있으면 숨이 꽉꽉 막힙니다~

    답글삭제
  4. 하늘이아빠님 안녕하세요.
    장문의 댓글을 남기셨네요.^^
    결국은 "조삼모사"죠. 그런데, 아침에 4개 먹기를 원하는 개발자나 경영자가 너무 많죠. 아침에 4개 먹으면 저녁때 3개가 아니고 1개 먹기도 어려운 것이 현실입니다. 아침에 3개만 먹으면 저녁에 4개 아니고 7,8개를 먹을 수도 있습니다.

    답글삭제
  5. 두렁청해님 안녕하세요.
    고객사별로 소스가 따로 노는 회사는 어느 순간 성장의 한계에 부딪히게 됩니다. 그 순간이 오면 이미 되돌릴 수 없는 상태가 된 겁니다.

    답글삭제
  6. 몇개 부분에서 리팩터링을 해야할 필요성을 느낌에도 불구하고
    계속 일에 치여서 다른 부분을 작성하다 보니 주렁주렁 늘어나는 코드를 보면서 눈물만 머금게 되는군요 ㅠ.ㅠ

    음.. copy&paste문제는 아마도 설계상의 문제가 가장 크지 않을까 생각이 듭니다.
    비슷한 기능이지만 약간의 다른 처리를 요구하는 함수가 발생할 때,
    전용 함수로 만들면 간단하게 해결되는데
    copy&paste하지 않기 위해서 두가지 기능을 하나로 합치다 보면 범용 함수가 되고
    그렇게 되면 상당히 귀찮아 지니 말이죠. 물론 범용 함수가 좋고
    여러개의 함수를 합쳐서 하나로 쓰는 것도 좋지만 대부분의 외각체크 루틴들은 거의 copy&paste 식으로
    비슷비슷하게 쓰여지는데, 이 부분을 명확하게 처리할 방법이 없는거 같더라구요.

    머.. 저의 프로그래밍 실력의 부족이 가장 큰 원인이겠죠 ㅠ.ㅠ

    답글삭제
  7. 구차니님 안녕하세요.
    범용함수란 그리 좋은 선택이 아니죠. 함수는 한가지 일만 하면서 간결하게 작성되어야 하죠. 그리고 리팩토링 시기를 놓치면 점점 혼란스러워지죠. 뭐든지 제때에 해야죠.

    답글삭제
  8. C&P 를 하고 향후에도 계속 C&P 를 하는 것이 과연 '개발자의 잘못' 으로 '해고되어야 마땅한' 일인지는.. 모르겠군요. 개발자 중 C&P 를 좋아서 하는 사람이 있을까요?

    C&P 에 대해 이리저리 생각하면..
    * 어찌 되었건 회사 입장에선 가장 빨리 답을 냈고 (해당 기능에 대해선 가장 빨리 답을 낼 가능성이 높습니다.)

    * C&P 를 한 다음에 부정적 피드백이 바로 날라오는 것도 아닙니다. (CPD 나 simian 같은 것을 회사차원에서 daily test 로 돌리지도 않고) 매일 매일 다음 할 작업으로 로드가 걸린 개발자 입장에선 일종의 시간 벌기가 됩니다. 밑의 돌 빼서 위에 꽂기 같은.

    * C&P 를 하는 당시에는 '이건 잠깐이고 언젠가 다시 리팩토링 할꺼야' 라 생각한 뒤, 실제로 리팩토링을 하지 않거나 하지 못하게 될 상황이 바로 닥치게 될 경우가 많습니다. 예전에 어떤 분 말씀처럼 '지금 당장 정리 하지 않으면 지는거다' 라고 강하게 생각하지 않고선 쉽지 않습니다.

    * 코드리뷰의 경우 리뷰를 1주일 이내 단위로 자주 하는 것이 아닌 이상 C&P 가 고쳐질 것이라고는 생각치 않습니다. 리뷰의 주기가 길 경우, 이미 리뷰 받고 난 뒤엔 돌이킬 수 없게 되는 경우가 많습니다. 리뷰 중 자주 나오는 말 중 하나가 '이번엔 어쩔 수 없으니.. 다음번엔..' 일겁니다. 소 잃고는 외양간 고치려고 해봤자 고칠 맘은 안생깁니다.

    답글삭제
  9. 안녕하세요. 질문도 답도 댓글에 다 포함되어 있군요. :)
    개발자 중에는 C&P의 폐해를 모르고 마구 해대는 사람들도 많습니다. 이미 많은 고민을 하고 계시네요.

    답글삭제
  10. 글 잘 읽었습니다 좋은 내용이 많아서 이건 무슨 말인가 하고 봤는데 흠.. 저는 Copy & Paste 신봉자거든요.
    API에 대한 오타를 막을 수 있고, 생산성도 향상된다는 점에서 무척 좋아합니다. 단지 이 글의 요지를 제가 처음에 오해했나봅니다.

    진짜 요지는 공통되는 부분을 모듈화하지 않고, 여기저기 똑같은 소스를 산재하는 것을 말하는거군요. 그건 저 역시 반대합니다!! 여기저기 같은 소스를 복사&붙여넣기 하면.. 자원낭비도 심하고
    유지보수하기도 여간 까다롭죠! 근데 ㅋㅋㅋ 재미는 있네요 ㅋㅋㅋ 고쳐야 할게 많아서 ㅋㅋㅋ

    답글삭제
  11. 빈익빈 부익부 라는 말이 떠오릅니다. 크고 체계가 잘 잡혀 있는 회사에 들어가서 체계적으로 일을 하면서 성장해 가는 사람이 있겠지만, 중소기업이나 그이하의 작은 업체에서 일하는 사람들에게 C&P의 남발은 도무지 버릴수가 없는 기술(?)이겠죠. 물론 작은 업체라고 해서 다 그렇지는 않겠지만요..

    답글삭제
  12. 우리나라에서는 대표적인 큰 회사들에서 이런 일이 흔히 벌어지고 있습니다. 모 휴대전화 회사도 수천개의 모델을 Copy&Paste에 기능 추가해서 만들어서 소스코드가 수천벌이 있다고 합니다. 과정이야 문제가 있고 개발자들이 고생하고 역량이 바닥이라고 해도 휴대전화를 잘 만들어서 팔고 있으니 이또한 대단한 역량이라고 하지 않을 수 없습니다. ^^
    이런 예를들어서 일반화하면 곤란하겠죠. :)

    답글삭제
  13. c&p 를 많이 한 것이 문제기도 하지만, 주기적으로 리팩토링을 해서 이런 부분을 없애지 않는 것도 큰 문제입니다. 일을 하다 보면 무엇이 공유될 지 미처 생각지 못한 부분이 생기기도 하고, 공유하려면 더 많은 고려를 해야 하기 때문에 일정상 미뤄놓을 때가 많습니다. 이런 것들은 주기적으로 공통 요소들을 찾아내 따로 관리하고, 이렇게 만든 공식 코드를 사용하도록 기존 프로젝트를 수정하는 작업이 필요합니다. 하지만 현실은? ㅡ,ㅡ;;

    답글삭제