C와 C++ 경계선에 대한 궁금증요....

물론 refactoring 이 훌륭한 도구임에는 당연합니다.
하지만, (예전에도 언급한 적이 있습니다만..) refactoring이 적용되기 힘든 부분또한 많습니다.
실례로 project갯수만 100개가 넘습니다. 하나의 dsw에 묶인 dsp만요...
각 dsp내에 class만 60개가 넘는것들이 매우 많습니다.
그중 core라 할 수 있는 dsp가 약 10개 내외 됩니다만, 그 core들의 tree(라기 보다는 hierarchal dependency죠..) dependency를 곁가지로 나머지 90여개의 dsp가 또한 서로간의 그리고 core와의 dependency를 가집니다. 물론 resource만을 전담하는 dsp도 있습니다.
90여개의 dsp에 해당하는 것은 toolkit이라 부르고 있습니다만.
toolkit을 개발하는 인원이 core에 해당하는 부분을 손대야할 경우가 적지 않습니다.
새로운 기능을 추가하기 위해서요...
전체 개발인력이 10~15명 정도 되지만, 각자 자신의 일이 할당되어 있겠죠...
이쯤되면 각자 모든 개발인력이, 자신의 일을 처리하기 위해서, core에 필요한경우 소소의 추가&수정을 해야만 하는 경우가 빈번하게 발생합니다.

operation 추가의 경우에는 별 고민이 없겠지만, operation 수정에는 고민이 많게 됩니다.
(operation수정을 function의 수정과 function들간의 동작의 수정을 포함하여 말하겠습니다.)
core 의 base 에 해당하는 하나의 함수를 고쳐야 할 경우, (주로 기능확장을 위해서입니다만...)
기능확장을 위해서 그 함수의 definition이 바뀌게 됩니다. 그로인해 그 class를 상속받고있는 다른 class들의 동작을 보장하기 위해서 모든 다른 class의 그 확장된 function의 definition을 모두 바꿔줘야 하고, 그들간의 동작에 대한 확인또한 필요하게 됩니다. 이럴경우 전체에 대한 안전성을 검사하기 위해서 전체를 컴파일 해야만 하게되는데, 소스의 모든부분을 전체 컴파일 하게 되는경우 10시간이 넘는 시간이 소요되게 됩니다. 물론 dependency가 적은곳은 부담이 적을수도 있겠습니다만, 고민이 된다면 dependency가 큰 곳이라는 것쯤은 쉽게 짐작하실 수 있을 것입니다.
즉 기능확장을 위해, 그 확장된 부분을 확인사살 하는데 걸리는 시간이 너무 심각하다는 점입니다. (compile 오류를 수정하는데만요..)

또한, 그러한 function들이 변경되는 것에대해, 매번 다른 팀원들에게 전달하여 숙지시키는것 또한 어려운 일입니다.
각자의 일정이 있기 때문이기도 하구요, 어찌보면, 필요한 사람이 알아서 보면 되기 때문입니다. 그래서 핵심적인/근본적인 변화 외에는 각자 알아서 보게 됩니다.
이쯤에서 다른사람이 그 수정된 것에 대한 부분을 보게 됩니다. 자신이 알던 포멧과는 다른형식으로 바뀌어 있기 때문에...
그 변경에 대해서 알아야만 작업의 진행이 가능합니다. (물론 document가 충분하다면, 그러한 고민이 적을수 있습니다만,
이정도 분량의 프로젝트라면, 하나하나 만들어나가고, 변경시켜 나가는데에 따른 document의 생성과 수정이 도리어 budden some 한 작업이 되기 시작합니다.) 이럴경우 일반적으로 자신이 알던 것에 대한 부분을 기초로 넘어가는것이 대부분입니다만, 그러한 일로인해 문제가 될 경우, 자신이 제대로 동작을 이해하고 넘어가지 않은것이 문제가 되기때문에, 책임(이라고 할 것 까지는 없지만...)은 나중에 사용한 사람에게 있게 됩니다.

또한, 저정도의 project라면, refactoring 도구가 알아서 처리하기에는 좀 버거운 량이라고 보여집니다.
물론 C++로 작성되었기에 적절한 refactoring 도구가 없는것 또한 문제입니다만... 그리고, 각자 자신이 알고있는 기존의 내용을 기반으로, base class의 내용을 확장해 나가기 때문에, refactoring 등을 통한 class/function 의 definition의 잦은 변경이 다른 작업자에게 부담을 안겨주게 됩니다. (머 실제로 적용시켜 볼 수 없었다는게, 가장 큰 결점이겠지만, 실제로 적용시키기도 힘듭니다. 하위 dependency들을 모두 찾아서 정리해줘야 하기때문에, 쉽사리 손댈수가 없는거죠.. definition이나 use나...)
"이쯤되면 누구나 자유롭게 수정" 이란 수식어는, 그 많은 분량의 내용을 기억하고 있는데, 어느부분의 내용이 변경되었는지 나도 모른다. 즉 "바뀐부분의 소스분석이 새로운 작업을 하기 이전에 항상 확인을 해야 한다"는 점으로 이어지게 됩니다.

또한 refactoring과 TDD의 경우에는 내용 변경시마다 testing에 의한 확인사살을 기정사실화 하고 있습니다만.
기존의 프로젝트가 testing을 위한 기반하에 개발되지 않았고, 또한 event deriven system에 있어서 testing을 할 수 있는 시점은 function level에 한해서 입니다. (머 UI를 테스트 할 수 있는 테스트 도구가 있는것으로 알고 있습니다만 (최근에 알았습니다..) 윈도우의 버튼을 클릭하는것이 아니라, view의 클릭위치에 따라 다른동작을 하는 시스템이라면, 이러한 테스팅 도구마저 적용이 불가능합니다.) function level 에서의 test 또한 function의 definition 혹은 추상화된 전반적인 operation 의 정의가 바뀌게 되면, 소용없게 됩니다. (머 충분한 test code가 이미 있지 않으니 이에대한 언급도 필요없군요...)

이밖에 많은 문제점이 있습니다만...
지금 생각나는건 이정도 이군요...
하나의 프로그램을 키워나가면서 현재의 확장버전만 3년 이상 manage하고 있습니다.
프로그램의 dependency와 규모는 계속적으로 커져나가면서요...
이런상황에서 refactoring이라는 훌륭한 도구는 "그림의 떡"에 지나지 않는군요.. "TDD"도 말이죠...
또한, 팀원 각자의 언어 혹은 개발 방법론에 대한 이해의 깊이의 차이 또한, 디자인과 개발효율성의 측면에서 어느정도 blockage역활을 하는것도 있구요...

이쯤되면, 호출된 함수에 대해서, 어느정도 신뢰를 할 수 도 있지만, 그렇지 않은경우도 많게됩니다. 즉 그 함수의 소스를 뒤져봐야 하는것이죠...
또한 리펙토링을 통해 신뢰성이 높아진다고 할 수 없게 됩니다. 리펙토링 자체가 버겁고, 버그를 유발할 수 있는 작업이 되기 때문이죠..
결국 현실적으로 불가능한 "주어진 코드를 개념적으로 가장 깔끔하게 유지하는 방법중 하나는, 처음 설계되었을때 그대로 이후로 계속 가져가는 것" 이란 얘기가 나오게 되었네요...
refactoring, TDD 매우 좋은툴 입니다만, 적용가능해야 하다는 전제가 필요한 듯 합니다...

PS:
예전에 다른 주제에 올렸던것과 같은 내용을 다시 올리게 되는구요..
좋은모습 아닌데.. ㅡ.ㅜ
이런글 좀 자제해야 할 듯 하네요. ^^;;;

PS:
refactoring, TDD 지금의 현실로는 적용 가능하지 않습니다.
하지만, 좀 방법을 생각해 봐야 할 듯 한데.. 쉽지가 않네요..
너무 긴 글을 작성했군요. 죄송합니다..
^^;

PS:
refectoring 이라고 된 것을 refactoring 으로 고쳤습니다.

직접 상황을 보지 못하면..
그 상황에 대해서 이해하지 못하는것이 대부분입니다.
다른분들께서 여러가지 지적을 해 주시지만, 다들 자기가 봐온 환경과 개념의 기준으로 문제를 판단하기 쉬운건 당연합니다.
이러한 문제들에 대해서 혼자만의 노력으로 고쳐지는게 아니기때문에,
여러가지 좋은 의견과 방법이 있지만서도 직접적인 적용이 가능한 경우와, 가능하지 않은 경우도 있습니다.
Design이 문제라는것을 이미 알고 있었지만, Design을 바꿀수가 없는것과,
Refactoring/TDD가 좋은 방법임에도 불구하고, 적용시킬수 없는 것 등....이 그러한 경우라고 생각합니다. 만...

그럼 M$의 수만 개발자들이 쓴 MFC도 API를 Wrapping 했으므로 대략 무효~!

저도 동감입니다.
C++ 에서 무언가 부족한 2%를 느끼는 경우가 많습니다.
TDD야 특별한 툴에 크게 의존적인것이 아니지만 (있음 더욱 좋겠죠),
Refactoring의 경우에는 툴 없이 하는것과 환경적인 문제로 많은 불편함을 느끼기에,
그냥 필요한 경우에만 간단히 적용할 수 있고, 가능한 부분에 조금씩 테스트 없이 하고 있습니다만
너무많은 제약에 답답함이 좀 크게 남네요..
저 또한 VM을 이용하는 것이 아닌 이상 C보다 C++, SP 보다 OOP가 낫다라고 생각하고 있습니다.

제가 알기로는 (틀릴수도 있습니다만...)
C++에서 Refactoring, static analysis(용어가 이게 맞는지는 모르겠군요) 를 해주지 못하는 가장 큰 이유중에 하나가,
static type casting에 있다고 알고 있습니다. (맞나요?)
그렇다면, 차라리 C++의 그러한 몇가지 불안전한 부분을 없애고 (C와의 완벽한 호환이 좀 떨어더라도),
Refactoring 등과 같은 것을 처리할 수 었으면 하는 바램이 있지만... 희망사항 뿐이겠죠 ? ^^

우선 한 가지.
object should not be based on class.
이를테면 자바에서 배열은 class에 기반하지 않지만 객체로 취급됩니다. 파이썬에서는 함수나 메쏘드도 객체로 취급되죠.

모든 것이 객체인 언어는 구성 요소가 모두 객체로 취급될 수 있는 것을 말합니다. 이를테면 순수 객체지향 언어라고 할 수 있는 smalltalk 같은 언어는 문자열은 물론이고 숫자, boolean 등도 모두 객체입니다. 파이썬도 마찬가지죠.

마지막으로, 디버깅이 gdb 같은 툴을 이용한 디버깅을 말하는 것이라면 이 점에서는 OOP가 SP보다 유리한 점은 제로입니다. 기본적으로 디버깅은 "따라가면서 버그를 찾는 방법"이므로 디버깅할 때는 레이어가 많고 개입하는 객체가 많을수록 따라가기는 어려워지는 것이 사실입니다. 그래서 OOP에서는 디버깅보다 테스트로 버그를 찾습니다. 실제로 TDD의 주창자 Kent Beck은 모든 디버깅은 테스트로 대체할 수 있다고 합니다. 디버깅 vs 테스트에 대한 논의도 많았는데 대체적으로 디버깅이나 테스트나 문제를 해결할 수 있다는 점은 같지만 테스트는 그 고민의 결과가 코드로 남는다는 점이 장점이 된다는 이야기가 많더군요. xper.org에서도 이런 논의가 있었는데 아쉽게도 오늘 이 사이트가 접속이 안되서 링크를 못 걸겠네요.

RTTI는 C++에서도 지원되고 C/C++에 function pointer도 있지만 그렇다고 C/C++에서의 function을 객체라고 하긴 좀 곤란하죠. 파이썬의 function object는 객체처럼 파라미터로 전달될 수도 있고 대입될 수도 있고 속성도 가지고 있죠. 단순한 behavior object가 아닙니다.

그리고, 다음에 쓰신 부분들을 보니 OOP의 레이어가 상속에 의해서만 생긴다고 생각하시는 듯 합니다. CN님도 아마 그런 생각을 하고 있으신 것 같구요. 그리고 실제로 이 상속이야말로 OOP의 오용이 나타나는 결정적인 이유이기 때문에 그렇게 생각하시는 것 같습니다. 실제로 상속은 OOP에서 그리 권장되는 방법이 아니며 출판된지 10년이 되어가는 GoF의 디자인 패턴에서도 상속은 좋은 방법이 아니며 웬만하면 합성을 통해 문제를 해결하라고 하고 있습니다. 실제로 OOP에서의 레이어가 나타나는 형태는 SP에서 나타나는 형태와 크게 다르지 않습니다. function 안에서 다른 function을 호출함으로써 SP의 레이어가 생기듯, object의 method 안에서 다른 object의 method를 호출함으로써 OOP의 레이어가 생기는 것이죠.

움. TDD나 리팩토링에 대해 "좋은 방법"이라고 말씀하시는 것을 보고 TDD와 리팩토링에 대해 잘 아시는 줄 알았는데 그게 아닌 것 같군요. 건방진 말로 들릴지 모르겠지만 이 부분에 대해서 조금 공부를 해보시는 것이 도움이 될 것입니다. Martin Fowler의 Refactoring이나 Kent Beck의 Test Driven Development by Example을 한 번 읽어보시길 권합니다. 둘다 번역서가 있고 번역이 꽤 잘 되어 있습니다. 테스트나 리팩토링에 관한 책들은 모두 공통적으로 테스트야말로 과감한 리팩토링을 할 수 있는 원천이라고 말하고 있습니다.

그리고 이와는 별개로, 이제 xper이 복구되었기 때문에 지난 번에 링크하려했던 주소를 적어둡니다.
http://xper.org/wiki/xp/AreDebuggersWasteful?action=highlight&value=%B5%F0%B9%F6%B1%EB

제가 하나 착각한 것이 있군요. TDD by Example은 why test보다는 how to test에 대한 설명 중심이라 제가 말한 그런 내용이 명시적으로 나오진 않는군요. JUnit for pragmatic programmer랑 착각한 것 같습니다. 리팩토링에는 명시적으로 잘 설명이 되어 있습니다.

사실상 코드를 수정할 때 테스트도 수정해야하므로 유동성이 떨어진다는 논리는 TDD에 대한 주요한 반론인 코드를 만들 때 테스트도 만들어야하므로 추가 비용이 발생한다는 것과 같은 논리죠. TDD는 테스트를 먼저 작성하고 코드를 작성하는 것이므로 수정할 때도 테스트를 먼저 수정하는 것이 당연한 것이고 이게 추가 부담으로 느껴진다면 TDD 자체가 성립할 수 없는 것이죠. 그래서 TDD를 좋은 방법이라고 말씀하시면서 위와 같은 말씀을 하시는 게 좀 이상했습니다. 그리고, 실제로 변경이 잦은 프로젝트를 할 때 TDD로 해보면 테스트가 있기에 변경을 자유롭게 할 수 있다는 말이 참 와닿게 되기에 htna님이 아직 TDD를 별로 해보지 않은 것 같다고 생각한 것이죠.

코드를 수정할 때 제일 골치아픈 부분이 뭘까요? 여러 가지가 있겠지만 정작 골치아픈 것은 수정한 그 부분보다 자신이 수정한 코드 때문에 다른 잘 되던 곳에서 문제가 발생하는 것일 겁니다. 큰 시스템일수록 이런 게 더 심각한 문제가 되죠. 테스트는 이런 점을 효과적으로 발견할 수 있게 해 줍니다. 수정한 코드 때문에 다른 곳에서 문제가 생기면 바로 전체 테스트에서 빨간 불이 떠서 금방 찾아서 고칠 수 있거든요. 테스트의 장점은 문제를 빨리 드러내준다는 것이고 그래서 내가 고친 코드가 맞는가, 다른 코드에 영향을 주진 않을까 고민할 필요 없이 과감하게 수정을 할 수 있는 것입니다.

TDD와 리팩토링에 대해 좀더 알아보시길 권하는 것은 굳이 이런 토론을 하기 위해 그런 것들을 다 알아야한다고 말하고 싶은 것이 아니라 그것이 OOP에 이르는 방법으로 현재까지 발견된 것 중 가장 좋다고 생각하기 때문입니다. 그래서 그것들이 습관이 되면 OOP는 자연스럽게 스며듭니다. 마침 TDD by Example을 읽고 있으시다면 실무에 전면적인 적용을 한 번 해보시길 강력히 권합니다. 아마 생각이 많이 바뀔 것입니다.

개발자 입장에서보면 편리하고 쉽게 구현하고 성능좋은게 우선이라고보봅니다.

그러면 oop 과연 얼마나 편리하며 쉽게될지 구체적으로 따져봐야죠..

oop로 하면 코딩량이 더적을까...
속도가 더빠를까..?
설계가 더쉬울까? 개념자체가 증가하는만큼 고려할것도 많겠죠.
그리고 배우기도 쉬워야하는데 아무래도 배울것도 증가하니.
그또한 단점이군요..

C++이 C보다 우수하다고 말하는사람이 있다면
최고의 언어는 C++에다 java 에다 php, basic, 코볼,파스칼,C#
등등등.. 컴파일러들 다묶어놓고 최고언어라고 하면되겠네요..^^