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

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

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

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


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

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

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

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

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

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

계속 분발해야겠습니다.

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

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

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

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

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

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

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

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

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

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

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

포스팅 잘 읽었습니다. CMMI에서도 요구사항에 대해서 요구사항을 먼저 "개발" 하고 그 다음 레벨이 요구사항 "관리"입니다. 지속적으로 요구사항이 바뀌기 때문이지요. 본문의 내용과 비슷한 맥락이라 허접 답변 남기고 갑니다. ^^

어쩌면 가장 중요한 차이점은,
요구사항이 변경되고 나서 재계산되는 시간, 비용의 차이가 아닐까 생각이 됩니다.
한국에서는 변경되도 마감일이나 비용이 변하지 않으니 말이죠..

포스트 하나하나 피가 되고 살이 되는 규현님의 포스트들.
오늘도 잘 봤어요. ㅎㅅㅎ

다섯번째 너무 공감가네요 ㅎㅎ

물론 조직원들의 변화에 대한 의지가 중요하겠습니다만. 왠지 모든 화살이 개발자 한테 꽂히는것 같네요. 뜨끔!

점점 배울수록 작아지는 자신의 모습에 우울증에 빠지지 않는것도 중요 한것 같습니다.
어떻게 배우면 배울수록 더 배워야 하는게 늘어나는지 참으로 미스테리입니다 ㅠ.ㅠ

포스팅 잘 읽었습니다. 뭐 개인적인 잡담수준입니다만, 약간의 운도 따라야 하겠죠..? ^^;

저하고 비슷한 생각을 하고 계신것 같아 예전에 적었던 글에 트랙백합니다.

전 아직 중1이니까 시간은 충분한데 영어랑 좀 많이 친해져야 겠네요. ㅎㅅㅎ

그래서 그런건지 네이버에서 코딩하면서 답을 찾고 있는 사람은 싫어하죠.

수업시간에 프리젠테이션으로 교수님이 이야기 하시는 객체지향 한학기 지나도록 이해를 못했는데 군대가서 원서를 정독하니 이해를 하겠더라구요 -ㅁ-

아직은 IT쪽에 대한 포스팅의 질이 낮은 편이라.. 아무래도 영어자료를 찾게되고, 번역내용들 역시 검증되지 않고 오역이 너무 많아서 그냥 원서로 보게 되더라구요.. 후우..

비밀댓글 입니다

영어의 필요성은 굳이 영어로 된 자료를 읽는데만 필요한 건 아니더군요.
해외업체랑 일을 하게 되면 결국은 공통어가 필요하고 이 공통어는 십중팔구영어가 되는 것 같습니다.

회의도 영어로 해야하고, 그날의 회의결과도 곧바로 정리해서 MOM 싸인받아야 하고, 이메일로 의사소통도 해야 하고, 영어 PT도 해야 하고...

그나마 상대방 클라이언트가 영어 네이티브면 어떻게든 말을 알아들어 줄텐데, 양쪽 모두 네이티브가 아닌 경우에는 좀 난감할 겁니다. 특히 본인도 영어를 못하고 상대방 담당자도 버벅이게 되면... 이건 재앙의 수준이라고 할지.. ㅎㅎ

오랫만에 들러서 글 읽고갑니다.

지금 회사에서 svn을 쓰고 있습니다. 그냥 깔아서 쓰고 있죠. 문서공유와 프로젝트 소스코드를 관리하기 위함입니다.하지만 svn담당자는 branch가 뭔지,tag가 뭔지, merge기능이 뭔지 모르더군요. 그냥 계정주고 인스톨만 하면 끝인줄 압니다. 안타깝죠~.그렇게 깔아놓고 후배들에게 무언가를 가르칩니다. 안타깝죠.~

비밀댓글 입니다

결론은 버전 컨트롤 인가요 ㅋ
아직 태그만 사용해봤지 브랜치는 사용해 보질 않아서 ㅠ.ㅠ 한 10% 기능밖에 못쓰는거 같아요

그래서 우리 팀엔 규칙이 있죠.. 먼저 커밋한 사람이 이기는거다.. ^^;

ㅋㅋ 가장 먼저 커밋 하는 사람이 장떙? ㅋㅋ

저희는 ClearCase를 쓰고 있는데...
"소스코드관리시스템을 이용하고 계십니까?" 라는 질문에 "No"라고 해야 할듯 싶네요..에공~

좋은 말씀입니다. 문제는 잘못된 길로 들어섰다는 것을 깨우치는 회사가 드물더군요... 깨우치게 하는 것이 가장 큰 장벽인것 같습니다.

자가진단 만큼 어려운것도 없죠 ^^;

솔찍히 기초만 다지라고 해서 될일은 아니라고 생각이 됩니다.
교육기반 자체가 암기식이고 왜? 라는물음을 배제한 채 다 커버린 교육의 결정체인 개발자에게 초심으로 돌아가라는건 개인에게만 너무 책임을 전가하는 행위라고 보여집니다.
물론, 살아남기 위해서라도 스스로가 기반을 다져야 하는 것은 옳지만 말이죠.

저도 컨설팅일을 하고 있지만 레퍼런스라는 것은 중요한게 맞는것 같습니다.
특히 같은 업종이나 같은 나라의 레퍼런스라는 것은
이미 경험을 해봤고, 문제가 무엇임을 알고 있기 때문에, 좀더 프로젝을 제대로 돌아가기 때문에 레퍼런스가 중요한 것 같습니다. 그리고 C레벨 경영자가 ROI를 따지는 것은 당연한 일이구요. 돈받고 무언가를 팔려면 그만한 가치를 하고 증명을 하는게 당연한 일이겠지요.
국내 소프트웨어 수준에 대해서는 외국 컨설턴트와 많이 일을 해봤지만 구현 기술에 있어서는 어느 나라 못지 않습니다. 프로세스 부분에 특히 관리 부분에서는 문제가 많지만 국내 고객 요건이 해외에 비해서 훨씬 까다롭고 더 높은 수준의 요구사항이 많기 때문에 국내 환경이 꼭 나쁘다 수준이 낮다고는 할 수 는 없을것 같습니다.

컨설턴트이던 개발회사이든 레퍼런스는 클라이언트가 안심하고 일을 맞길 수 있느냐 없느냐를 결정하는데 중요한 사항 중 하나라고 생각합니다.

예를 들어 개발회사 A가 국내 최대 이통사에 솔루션 K를 납품하고 운영한 경험이 있다고 하더라도 이건 가입자 2천만명을 처리한 경험이 있다라는 이야기밖에 되지 않죠.
이런경우 가입자 6천5백만명을 갖고 있는 해외 모 이통사에서는 해당 업체 A에 뭔가를 맞기기에 불안할 수밖에 없을겁니다. 수치상으로도 3배가 넘는 트래픽을 감당해야 하니...

그래서 많은 회사들이 양질의 레퍼런스를 늘릴 기회가 된다면 적자를 감수하고서라도 프로젝틀를 진행하려고 하는게 아닐지요.

글 잘 읽고 갑니다.

컨설팅 전/후 효과에 대한 분석을 위해 어떤 요소들을 측정하나요? 생산성과 운영비용에 대한 측정, 결함율 분석, 잠재 리스크 및 리스크에 대한 비용과, 프로세스 개선 뒤의 생산성 향상 및 운영비용 감소, 결함율 감소, 리스크 감소 등에 대하여 정량적 혹은 정성적으로 어떻게 분석하는지 궁금합니다.

Reference는 둘째 치더라도 정성/정량적인 사항은 담당자 선에서 보고서엔 필수적으로 포함을 시켜야 하기때문에 요구할꺼에요. 또 컨설팅 입장에서의 고객 Case Study, 고객 만족도/반응도 를 제시하여 주는 것도 좋은 마케팅 툴 중에 하나죠.. 국내 Infra가 취약하긴 하지만.. 그래도 취약한 Infra의 담당자 및 임원을 객관적인 자료로 제안/설득 및 향후 도입효과를 측정해주는 것도 컨설팅 회사의 주요 Activity이지 않나 싶습니다.

멋진 이야기세요~

확실히 전문적으로해야 한다는 점에서는 맞긴 하지만..
문제는 회사에서는 슈퍼맨을 원하죠.. 한사람으로 세사람 역활을 하는 그런 것들을 말이죠..

하지만 개발자가 코딩을 위해서는 저러한 방법론적인 이론들도 알고는 있어야 합니다
그러면 또 윗사람은 당연히 그것도 해야 하잖아? 라고 하고.. 참.. 악순환이군요..

글 내용에서는 개발과 테스팅의 체계적인 분리 필요성을 역설하셨지만, 제목은 그렇지 않네요 ㅋ

규현님 블로그의 특징은 글이 띄엄 띄엄 올라오는 대신 그 글들 하나 하나가 좋은 듯....

그런데 텍스트큐브 블로거는 티스토리 블로그를 관심 블로그로 설정할 수 없나요? 전 텍큐라서....

각 개발자별로 1개의 전담분야를 맡아 처리하려면 부서가 최대한 작게 나눠저야 하고(프로젝트를 진행하는) 팀장의 수도 작아야 하죠 ㅎㅎ 안 그러면 팀마다 개발자/DBA/아키텍터.. 등등이 필요로 하게 되니... 네네.. 뭐 일단 현실은 말씀하신 것처럼 개발자가 제안서 작성/해외출장 및 클라이언트 미팅/설계/개발/SQL튜닝/QA/인수인계 문서작성/교육/관리.. 까지 다 하는게 대부분의 중소기업의 현실인듯. 또 그런 멀티 플레이어를 중소기업일수록 선호하는게 사실이구요.

뭐... 팀원 모두가 유능한 멀티플레이어가 되는 것도 한 가지 방법입니다.

국내개발자는 슈퍼맨이 맞습니다. 워낙 여러가지 일들을 하기를 원해서요. 기본적으로 설계+코딩+테스터는 기본이고 상황에 따라 배포까지 해야하니까요. 그러니 외국에선 싼 가격에 여러가지 일들을 해낼 수 있는 국내 개발자를 선호하는지도 모르겠구요. 외국은 역활 분리가 완벽하게 되어있으니.