Don't Copy&Paste but Generalize or Gnerate!

kyagrd의 이미지

긁어붙이기(CopyAndPaste)는 프로그래밍에서 악의 축이다. 절대로 긁어붙이지 말고 GeneralizeOrGenerate 하라. 같은 일을 하는 부분의 코드는 전체 프로그램에서 하나만 존재해야 한다. 따라서, 같은 일을 하는 루틴은 단 하나로 빼서 일반화된 루틴을 만들든가, 그것이 프로그래밍 시스템 내에서 어려우면 코드를 생성하는 생성기를 만들어서 쓰든가 해야 한다. 이것이 바로 내가 말하고자 하는 GeneralizeOrGenerate 다. 그러나 CopyAndPaste 해서 적당히 고치는 식으로 만들다 보면 같은 역할을 하는 코드가 여러 곳에 산재하게 되고, 나중에 변형/개선할 일이 있을 때 그 중의 일부반 고치게 되면 엄청나게 골치아픈 문제가 발생하곤 한다.

수학자들이 하는 일이 놀랍게 보이는 이유는, 그들이 어떤 문제를 풀고자 할 때 오히려 더 풀기 어려워 보이는 일반적인 문제에 접근해 그것에 대한 해법을 구함으로써 처음에 풀려고 했던 특수한 문제를 해결하곤 하기 때문이다. 이러한 문제 해결 방법은 수학의 역사를 통해 공인된 것이다. 이러한 방법의 장점은 한 문제를 해결하는 데 그치는 것이 아니라 그와 비슷한 부류의 많은 문제들도 쉽게 해결할 수 있다는 것이다.

프로그램을 하는 것도 수학 문제를 푸는 것과 근본적으로 다를 바가 없다. 단지 주어진 문제만을 푸는 것이 아니라 더 일반적인 문제를 해결함으로써 주어진 문제를 푸는 것이 좋은 수학 문제 풀이이듯이, 좋은 프로그램이란 풀고자 하는 문제보다 일반화된 문제를 다룰 수 있는 프로그램을 통해 특정 문제를 해결하는 프로그램이다. 이러한 프로그램은 활용 범위가 넓을 뿐만 아니라 차후 프로그램의 변경이나 개선시 관리하기도 쉽다.

그러나 실무에서는 이렇게 당연한 사실을 무시하곤 하는 경향이 있다. 개발자들은 급한 일정 등을 핑계로 문제만을 겨우 해결하는 아무렇게나 만든 프로그램을 쏟아내곤 한다. 이럴 때 가장 흔하게 뼈져드는 유혹이 바로 비슷한 코드를 CopyAndPaste 해서 적당히 몇 군데 고쳐서 쓰는 것이다. 차리리 처음 맞딱드리는 문제라면 이런 유혹에 덜 빠지겠지만 과거에 해결했던 것과 유사한 문제를 풀 때 이런 유혹에 빠지기 쉽다. 루틴을 CopyAndPaste 해서 이것 저것 고치는 것을 아무 죄책감 없이 하는 분위기는 정말 큰 문제이다.

CopyAndPaste 와 같은 습관을 버리고 GeneralizeOrGenerate 하며 살아가자. 엔지니어의 의견이나 분석은 전혀 반영하지 않은 채 업무성과를 보이기 위한 프로젝트 기획이나 수주를 따기에만 급급한 주먹구구식 영업 관습 등, 나름대로 열악한 사정이야 있을 수 있다. 하지만 그렇다고 해서 타성에 젖어들면 개인은 물론이거니와 자신이 속한 집단도 발전이 있을 수 없다. 일정을 잘못 잡은 것은 엔지니어가 책임지고 고려해야 할 사항이 아니라 관리자의 임무이다. 개발자가 관심을 가져야 할 것은 프로그램의 품질이다.

http://mithrandir.xcool.net/~kyagrd/moniwiki/?GeneralizeOrGenerate&action=show&dummy=1

fibonacci의 이미지

멋진 글입니다. 수학공부가 업인 저에게는 매너리즘을 경계하라는 뜻으로 새겨듣겠습니다.

- 추론할수 없는 지식은 머리속에 새기지 마라

No Pain, No Gain.

angpoo의 이미지

긁어붙이기 대충 몇번하고
simplify *.c 해주면
중복되는 블럭을 unnamed_xx()로 묶어주고
중복되는 부분에서 차이나는 부분은 또 파라메터로 분리해주는
그런건 없을라나...

punxism의 이미지

흑 눈물 나는군요.

perky의 이미지

angpoo wrote:
긁어붙이기 대충 몇번하고
simplify *.c 해주면
중복되는 블럭을 unnamed_xx()로 묶어주고
중복되는 부분에서 차이나는 부분은 또 파라메터로 분리해주는
그런건 없을라나...

http://www.google.co.kr/search?q=refactoring.browser
http://c2.com/cgi-bin/wiki?RefactoringBrowser

You need Python

nachnine의 이미지

리팩토링의 일부 개념과 일맥상통하는군요 ^^

thedee의 이미지

리팩토링보다 깊은 얘기를 하고 있는 것 같습니다.
좀 더 high order한 얘기를 하고 있는 것 같고 리팩토링은
그 구체적인 방법론 중 하나가 아닐까 생각합니다.

덧글>
본문을 제대로 읽지 않고 댓글을 달았음을 살짝 고백. 본문을 마저 읽고 링크까지 따라가 봤는데 재미있네요... :D

수학의 방법론부터 실무 현장의 애환(?)까지 한큐에 나와 버려서 좀 혼란스럽기는 한데 제가 저 글을 읽을 때 머리에 떠올렸던 문장은 다음과 같은 것이었습니다.

Quote:

Instead of mixing the general and the specific, define the general and pass the specfic as an argument. (by 폴 그레이엄)
gurugio의 이미지

지금 알고리즘 과목 과제로 AVL 트리를 만들고 있는데요

다른 친구들은 어떻게 하는지는 몰라도

AVL 트리의 정의와 로테이션의 개념만 가지고

어떤 경우에 더블 로테이션인지 싱글 로테이션인지부터

좌우 균형을 계산하는 방법등등을 모두

혼자서 만들어보고있습니다.

지금도 만드는 중인데요 과연 제가 제대로 만들고있는지 확신이 들지는

않습니다만 제대로 안돌아가서 과제를 못내더라도

제가 수학문제를 풀던 방식처럼

정의와 lemma들을 가지고 스스로 풀어보려고 합니다.

그런데요 이런 방식으로 모든 것을 다 처리하려다보니

시간도 많이 부족하고 또 진도도 느립니다.

오히려 책보고 따라서 만들어보면서 이것저것 많이 해보는 친구들이

더 인정받고 아는 것도 많습니다.

회의가 듭니다.

미국에서는 스스로 풀어보는게 정석이라고 듣긴 했지만

제가 제대로 공부하는 건지 모르겠습니다.

그냥 인터넷에서 자료찾아서 읽어서 따라해보고

그대로 비슷하게 만들어서 내는게 더 효율적이지 않을까 하는 생각도 듭니다.

idlock의 이미지

gurugio wrote:

미국에서는 스스로 풀어보는게 정석이라고 듣긴 했지만

제가 제대로 공부하는 건지 모르겠습니다.

그냥 인터넷에서 자료찾아서 읽어서 따라해보고

그대로 비슷하게 만들어서 내는게 더 효율적이지 않을까 하는 생각도 듭니다.

이런 생각이 듭니다.. 고등학교때 수학을 보면 외워서 푸는 사람과 이해해서 푸는 사람이 있습니다. [아 물론 고등학교 수학은 외워서 풀면 다 풀리죠 --;;]

사람이 살아가는 길이 달라지면 어떤방식이 좋을지는 모르는것지만...

이해해서 푸는 사람은 어떤길로도 갈수 있지 않을까요.....

간단한 RSA 암호화를 프로그램밍 한사람이 결제처리 로직을 만드것과 매뉴얼대로 만드는것은 엄청난 차이가 잇다고 생각합니다.

특히 에러처리등의 예외상황 버그 상황에대한 대응 법이 달라지겠지..

현업이라면 그냥 시키는대로만해도 되겠지만.. 공부중이시라면 꼭해보시는것이 좋을것 같습니다.~! 파팅..