프로그램내에서의주석

아..Refactoring 하라는 거군요.. 사실 설계 자체에서도 빠진 상태라 전체 구조 이해하는데 가장 크게 애를 먹었습니다. 아무튼 진짜 이해한 후에 코드를 수정해 놓는 것도 좋은 방법인건 분명하다고 생각합니다. ^^; --창섭

좌절이다. 일단 자네 의견에 동의 정도가 아니라 같은 의도의 말이었다. 위의 자네 말에 대한 내가 의미를 불확실하게 전달한거 같아서 세단락 정도 쓴거 같은데.. 휴 일단 다시 짧게 줄이자면, "프로그래머의 낙서의 표준"인 UML과 ~cpp JavaDoc의 출발은 아예 다르다. 자네가 바란건 디자인 단위로 프로그래밍을 이해하길 원한거 같은데, 그것을 ~cpp JavaDoc에서 말해주는건 불가능하다고 생각한다. Sun에서 msdn에 대응하기 위해(?) ~cpp JavaDoc이 태어난것 같은데 말이다.

하지만, "확실히 설명할때 ~cpp JavaDoc뽑아서 그거가지고 설명하는게 편하긴 편하더라."라고 한말 풀어쓰는 건데, 만약 디자인 이해 후에 코드의 이해라면 ~cpp JavaDoc 없고 소스만으로 이해는 너무 어렵다.(최소한 나에게는 그랬다.) 일단 코드 분석시 ~cpp JavaDoc이 나올 정도라면, "긴장 완화"의 효과로 먹고 들어 간다. 그리고 우리가 코드를 읽는 시점은 jdk를 쓸때 ~cpp JavaDoc을 보지 소스를 보지는 않는 것처럼, 해당 메소드가 library처럼 느껴지지 않을까? 그것이 메소드의 이름이나 필드의 이름만으로 완벽한 표현은 불가능하다고 생각한다. 완벽히 표현했다면 너무나 심한 세분화가 아닐까? 전에 정말 난해한 소스를 분석한 적이 있다. 그때도 가끔 보이는 실낱같은 주석들이 너무나 도움이 된것이 기억난다. 우리가 제출한 Report를 대학원 생들이 분석할때 역시 마찬가지 일것이다. 이건 궁극의 Refactoring문제가 아니다. 프로그래밍 언어가 그 셰익스피어 언어와 같았으면 하기도 하는 생각을 해본다. 생각의 언어를 프로그래밍 언어 대입할수만 있다면야.. --상민

그리고, JDK 와 Application 의 소스는 그 성격이 다르다고 생각해서. JDK 의 소스 분석이란 JDK의 클래스들을 읽고 그 interface를 적극적으로 이용하기 위해 하는 것이기에 JavaDoc 의 위력은 절대적이다. 하지만, Application 의 소스 분석이라 한다면 실질적인 implementation 을 볼것이라 생각하거든. 어떤 것이 'Information' 이냐에 대해서 바라보는 관점의 차이가 있겠지. 해당 메소드가 library처럼 느껴질때는 해당 코드가 일종의 아키텍쳐적인 부분이 될 때가 아닐까. 즉, Server/Client 에서의 Socket Connection 부분이라던지, DB 에서의 DB Connection 을 얻어오는 부분은 다른 코드들이 쌓아 올라가는게 기반이 되는 부분이니까. Application 영역이 되는 부분과 library 영역이 되는 부분이 구분되려면 또 쉽진 않겠지만.

DeleteMe) 부연설명 : 녹색글자는 Eclipse 에서 내부 주석에 대당. IntelliJ 는 일반적으로 회색. Vi 에서의 Java Syntax 에선 파란색.

~cpp 
...
		// 자식들 다 쥑이고...
		CSmilNode* pChildNode = m_pFirstChild;
		while(pChildNode)
		{
			CSmilNode* pDelNode = pChildNode;
			pChildNode = pChildNode->m_pNext;
			pDelNode->deleteSafely(bRecursive);
			pDelNode = NULL;
		}

		// 형제의 연을 다 끊고...
		if(m_pPrev)
			m_pPrev->m_pNext = m_pNext;
		if(m_pNext)
			m_pNext->m_pPrev = m_pPrev;

		// 부모의 연도 끊은 다음...
		if(m_pParent  &&  m_pParent->m_pFirstChild == this)
			m_pParent->m_pFirstChild = m_pNext;

		// 자살한다.
		delete this;
...

~cpp 
...
// MODE_ADDBEFORE일 때는, newnode가 this의 자식인 brother의 바로 윗형으로 입양을 간다.
// MODE_ADDAFTER일 때는, newnode가 this의 자식인 brother의 바로 아래 동생으로 입양을 간다.
// 입양을 갈때, 자식들은 항상 데리고 다니지만, 부모나 형제와는 떨어지는 것을 원칙으로 한다.
// 새식구를 받을때, 먼저 부모 자식간의 관계를 정립한 다음, 형제간의 서열을 정립한다.
//
// Default Parameter
//	nMode = MODE_ADDBEFORE
//	brother = NULL
// Constraint
//	brother는 반드시 NULL이거나 this의 child node이어야 한다.
// 사용예
//	addChild(newnode, MODE_ADDAFTER, brother);		//newnode가 brother 바로 뒤에 삽입된다.
//	addChild(newnode, MODE_ADDBEFORE, brother);		//newnode가 brother 바로 앞에 삽입된다.
//	addChild(newnode, MODE_ADDAFTER);				//newnode가 first child로 삽입된다.
//	addChild(newnode, /*MODE_ADDBEFORE*/);			//newnode가 last child로 삽입된다.
//
CSmilNode* CSmilNode::addChild(CSmilNode* newnode, DCLADDMODE nMode, CSmilNode* brother)
//	this = 내(부모)
//	newnode = 자식(새놈)
//	brother = (this의 자식인)윗형
...