E D R , A S I H C RSS

프로그램내�서�주�


주�� 없는 코드�서 그런지 해�하는 � 애먹었다

그렇다면 ìž�ì‹ ì�´ ê·¸ 코드를 í•´ì„�하면서 ì–»ì�€ ì§€ì‹�ì�„ ê·¸ 코드ì—� ì �용했ë�”ë�¼ë©´(좀 ë�” ì�˜ë¯¸ìžˆëŠ” 변수ì�´ë¦„, ë©”ì�¨ë“œì�´ë¦„ 사용, 코드 ì�¼ë¶€ë¶„ì�„ ì�˜ë¯¸ìžˆëŠ” ì�´ë¦„ì�˜ ë©”ì�¨ë“œë¡œ ì¶”ìœ ë“±) ì–´ë• ì�„까요? --JuNe
아..Refactoring 하�는 거군요.. 사실 설계 �체�서� 빠진 �태� 전체 구조 �해하는� 가장 �게 애를 먹었습니다. 아무튼 진짜 �해한 후� 코드를 수정해 놓는 것� 좋� 방법�건 분명하다고 ��합니다. ^^; --창섭

처�� Javadoc � 쓸까 하다가 계� 주�� 코드� 아른 거려서 방해가 �었� 관계로; (IntelliJ 3.0 �후부턴 Source Folding � 지�하기 때문� Javadoc� 닫� 수 있지만) 주�� 안쓰고 프로그래�� 한게 화근�가 보군. 설계 시기를 따로 뺀 �� 없지만, Pair 할 때마다 매번 Class Diagram � 그리고 설명했� 것으로 기억하는�, 그래� 전체구조가 �해가 가지 않았다면 내 잘못� �지. 다�부터는 �민�처럼 위키� Class Diagram 업��트� 것 올리고, Javadoc 만들어서 generation 한 것 올리�� 노력� 해야 겠군.

요새들어서 주�� 잘 안쓰고 코드를 알아보기 쉽게 쓰려고 노력하긴 하는�, 아� 수련� 부족해서�지 코드는 코드대로 어렵고 주�� 주�대로 없나 보다. ��;

약간 변명��면, 개�� 경험�서는 주�� 달린 코드는 주�� 시선� 먼저가고, 주�� 없는 코드�는 함수 프로토타입� 시선� 먼저간다�는 것. 하지만, ��가 전해지지 않았다면 역시 � 무�미한것�겠지. --�천

내가 가지는 주�� 관�� 지하철�서� 언급한 내용 거� 그대로지만, 내게 있어 주�� 주� 용�는 과거� �신과 대화를 하면서 집중� 유지, 진행� 체�하기 위해서 �고, 기타 �유는 �반�� �유� 타�� 대한 정보 전달�다. 전�는 command.Command.execute()�나 �규와 함께 달� information.InfoManager.writeXXX()위� 주�들�고,후�가 주로 쓰� 용�는 � class �단과 package 기술해 놓� 주��다. 그외� class diagram� �래 아나로그로 그린것� 있지만, 설명하면서 그린건 절대로 타�� 머리�� 통째로 저장� 남지 않는다는 전제로, (왜�면 내가 그러니까.) 타�� 열람� 위해 class diagram� 디지털화를 시켰다. 하는 김� 그런� 확실히 설명할때 JavaDoc뽑아서 그거가지고 설명하는게 편하긴 편하��. --�민

�바 IDE들� Source Folding � 지�하거나 comment 와 관련한 기능� 지�한다면 해결�듯. JavaDoc � API군�나 Framework Library� 경우 MSDN� 역할� 해주니까. --�천

�네� 경우는 주�� �네� ��과정�고, 그 다�� 코드를 �는 사람� 관�� 건�, 프로그램� �해하기 위해서 그 사람� 어떤 과정� 거칠까? 경험� 있는 사람�야 무엇� 해야 할 지 아니까 abstract 한 �래스 �름�나 메소드들 �름만 �� 잘 �해를 하지만, 나는 다른 사람들� 실제 코드 구현부분� �기를 바랬거든. (소켓�서 Read 부분 관련 블럭킹 방지를 위한 스레드� �용방법� 모르고, Swing tree �용법 모르는 사람�� ��욱. 해당 부분� 대해선 Pair 중 설명� 하긴 했으니)

그리고 개��으론 Server 쪽 �해하기로는 Class Diagram � JavaDoc 보는것보다 � 편했�. 그거 본 다� 소스를 보는 방법으로 (완벽하게 �해하진 않았지만.). �건 내가 UML � � �숙해서가 아�까 함. 그리고 Java Source 가 비�� 깨�하기� �해하기 편하다는 �� 있겠고. (그래 소스 작성한 사람 칭찬해줄께;) --�천
좌절ì�´ë‹¤. ì�¼ë‹¨ ìž�네 ì�˜ê²¬ì—� ë�™ì�˜ ì •ë�„ê°€ 아니ë�¼ ê°™ì�€ ì�˜ë�„ì�˜ ë§�ì�´ì—ˆë‹¤. 위ì�˜ ìž�네 ë§�ì—� 대한 ë‚´ê°€ ì�˜ë¯¸ë¥¼ 불확실하게 전달한거 같아서 세단ë�½ ì •ë�„ ì“´ê±° ê°™ì�€ë�°.. 휴 ì�¼ë‹¨ 다시 짧게 줄ì�´ìž�ë©´, "프로그래머ì�˜ 낙서ì�˜ 표준"ì�¸ UMLê³¼ ~cpp JavaDocì�˜ ìœë°œì�€ 아예 다르다. ìž�네가 바란건 ë””ìž�ì�¸ 단위로 프로그래ë°�ì�„ ì�´í•´í•˜ê¸¸ ì›�한거 ê°™ì�€ë�°, 그것ì�„ ~cpp JavaDocì—�서 ë§�해주는건 불가능하다고 ìƒ�ê°�한다. Sunì—�서 msdnì—� 대ì�‘하기 위해(?) ~cpp JavaDocì�´ 태어난것 ê°™ì�€ë�° ë§�ì�´ë‹¤.

하지만, "확실히 설명할때 ~cpp JavaDoc뽑아서 그거가지고 설명하는게 편하긴 편하ë�”ë�¼."ë�¼ê³  한ë§� 풀어쓰는 ê±´ë�°, 만약 ë””ìž�ì�¸ ì�´í•´ 후ì—� 코드ì�˜ ì�´í•´ë�¼ë©´ ~cpp JavaDoc 없고 소스만으로 ì�´í•´ëŠ” 너무 어렵다.(최소한 나ì—�게는 그랬다.) ì�¼ë‹¨ 코드 ë¶„ì„�시 ~cpp JavaDocì�´ 나올 ì •ë�„ë�¼ë©´, "긴장 완화"ì�˜ 효과로 먹고 들어 간다. 그리고 우리가 코드를 ì�½ëŠ” 시ì �ì�€ jdk를 쓸때 ~cpp JavaDocì�„ ë³´ì§€ 소스를 보지는 않는 것처럼, 해당 메소드가 library처럼 ëŠ�껴지지 않ì�„까? 그것ì�´ 메소드ì�˜ ì�´ë¦„ì�´ë‚˜ 필드ì�˜ ì�´ë¦„만으로 완벽한 표현ì�€ 불가능하다고 ìƒ�ê°�한다. 완벽히 표현했다면 너무나 심한 세분화가 ì•„ë‹�까? ì „ì—� ì •ë§� 난해한 소스를 ë¶„ì„�한 ì �ì�´ 있다. 그때ë�„ ê°€ë�” ë³´ì�´ëŠ” 실낱같ì�€ 주ì„�들ì�´ 너무나 ë�„움ì�´ ë�œê²ƒì�´ 기억난다. 우리가 ì œìœí•œ Report를 대학ì›� ìƒ�들ì�´ ë¶„ì„�할때 역시 마찬가지 ì�¼ê²ƒì�´ë‹¤. ì�´ê±´ ê¶�ê·¹ì�˜ Refactoring문제가 아니다. 프로그래ë°� 언어가 ê·¸ ì…°ì�µìŠ¤í”¼ì–´ 언어와 같았으면 하기ë�„ 하는 ìƒ�ê°�ì�„ 해본다. ìƒ�ê°�ì�˜ 언어를 프로그래ë°� 언어 대입할수만 있다면야.. --ìƒ�민

난해한 코드�수� 주�� 필요한 것�것�고 (�는 그 반대로 쉽게 알아볼 수 있�� 짤 방법� 강구해야 한다면 억지쓰는 것�려나.) 개��으로 �어본 가장 긴 낯선 코드가 3000~4000 ��� 못넘어 본 관계로 아�� '정리' 단계로만 �날 것 같다. CVS � history 가 코드 진화과정� 따�가는� �움� 줄것��고 ��했지만, 아�� 먼 �야기�듯.

내가 Comment 와 JavaDoc 둘� 비슷한 대�으로 �고 쓴게 잘못�듯 하다. �개는 좀 구분할 필요가 있� 것 같다는 ��� 들어서다. 내부 코드 알고리즘 진행� 설명하기 위해서는 다는 주�� comment로, 해당 구성 �래스들� interface를 서술하는것� JavaDoc으로 구분하려나. � 경우�면 JavaDoc 과 Class Diagram � 거� 비슷한 역할� 하겠지. (Class Diagram � 그냥 Conceptual Model 정��면 � �야기가 달�지겠지만)

그리고, JDK 와 Application � 소스는 그 성격� 다르다고 ��해서. JDK � 소스 분��란 JDK� �래스들� �고 그 interface를 �극�으로 �용하기 위해 하는 것�기� JavaDoc � 위력� 절대��다. 하지만, Application � 소스 분��� 한다면 실질�� implementation � 볼것�� ��하거든. 어떤 것� 'Information' ��� 대해서 바�보는 관�� 차�가 있겠지. 해당 메소드가 library처럼 �껴질때는 해당 코드가 �종� 아키���� 부분� � 때가 아�까. 즉, Server/Client �서� Socket Connection 부분���지, DB �서� DB Connection � 얻어오는 부분� 다른 코드들� 쌓아 올�가는게 기반� �는 부분�니까. Application �역� �는 부분과 library �역� �는 부분� 구분�려면 � 쉽진 않겠지만.

�번기회� comment, document, source code � 대해서 제대로 ��해볼 수 있�듯 (프로그램� 어떻게 분�할 것�가 ��지 Reverse Engineering Tool들� �용하는 방법� �리한다�지 등등) 그리고 후배들과� 코드� 대한 대화는 �숙한 comment 로 대화하는게 낫겠다. DesignPatterns 가 한서� 나온다고 하며 �하나� 기술장벽� 내려간다고 하���, 접해보지 않� 사람�� �하나� 외국어�것�니. 그리고 �어가 모국어가 아닌 ��. �. (암튼 오늘 내� �는대로 Documentation 마저 남기겠�. 글쓰는 �중 치열하게 Documentation� 진행하지� 않� 사람� �만 앞섰다란 ��� 그치질 않는지�. 물론 작업중 Doc � 아닌 작업 후 Doc �는 ��서 �수 깎�다는 �� �지중;) --�천

DeleteMe)위� 좌절� �유를 안�놨는�, �세히 � 종류별로 ��� �어 놓았는�, commit시� 충�� 나서 먹어 버렸어. 하..하..하 ... 암튼 �번� 프로그래�� 하면서 ��한 컨셉들� 서로 설명하면서 같� �해야 겠군.

그리고 계� �야기 하다보니 주�(comment)과 ~cpp JavaDoc� 나누어 설명하는 것� 올바른 ���듯 하다. 그런 관���면 �번 코딩� 컨셉� 녹색글� 최소주�로 나갔다고 볼수 있다. 머리�으로는 특별히 둘� 나누지 않고 있었는�, 코딩 습관�서는 완전히 나누고 있었�거 같다. 녹색 글�를 쓰지 않�려고 발악(?)� 했으니.. 그래� 보�는 녹색 글�들 보면 죄��� �것� object world�서 �하는 "프로그래머� 죄��"� 해당하는 것� 아�까. --�민
DeleteMe) 부연설명 : 녹색글�는 Eclipse �서 내부 주�� 대당. IntelliJ 는 �반�으로 회색. Vi �서� Java Syntax �선 파란색.


재미있는 주�

주�� 실행� 수 있는 코드가 아니기 때문�, 반드시 코드가 주�대로 수행�다고 볼 수는 없지만 없는것 보다는 낳� 경우� 많다. 코드 �체는 언어� subset �기 때문� 아무리 코드가 �야기한다(code tells)� 할지�� 우리가 쓰는 언어� �해�� 미치기가 어렵다. �는 마치, 어떤 �� 함� 있어서 메뉴얼� 존재함�� 불구하고 경험��게 �야기를 듣고 메뉴얼� 볼 경우, 그 �해가 쉽고 빠르게 �는것과 비슷하다.

프로그램� 있어 주�� 하는 순기능� 하나 � 찾아볼 수 있다. 메마른 코드��서 사람� 숨결� ��게 해준다. 유머가 없는 세�� ��해보�. 얼마나 ��한가.

예를 들어 다�� 코드를 살펴보�(회사�서 누군가 작성한 코드)


~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� ���)윗형
...

�선우는 �러한 코드를 보며 여�때와 같� 지루함� ��지 못했다. (모든 주� 없는 코드가 다 지루하다는 뜻� 아니다. 분명 예술�� 코드는 코드 �체로 신비롭다. 문제는 �런 코드를 �주 만나기 어렵다는� 있다.) 정�, 재미있지 않�가?

우리는 충분히 �성��기� 주� �체만� 보고 모든것� 믿으려고 할 만� 어리�지는 않다. 주�� 먼저 거�간 사람� 숨길로 ��고, 재미로 �낄 수 있게 �면 코드 리뷰가 항� 지루하지는 않� 것�다.

코드 �체로서 �미를 �야기할 수 있�� �름� 잘 짓는 것� 분명 중요하지만, 그� 못지 않게 코드를 �고 작성하는 주체가 사람임� ��할때 주�� �들� 위한 작� 배려� 할 수 있다.

--�선우

See Also Seminar:CommentOrNot , NoSmok:DonaldKnuth 's comment on programs as works of literature
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:31:26
Processing time 0.0091 sec