주ì„�ì�´ 없는 코드ë�¼ì„œ 그런지 í•´ì„�하는 ë�° ì• ë¨¹ì—ˆë‹¤
ê·¸ë ‡ë‹¤ë©´ ìž�ì‹ ì�´ ê·¸ 코드를 í•´ì„�하면서 ì–»ì�€ ì§€ì‹�ì�„ ê·¸ 코드ì—� ì �용했ë�”ë�¼ë©´(좀 ë�” ì�˜ë¯¸ìžˆëŠ” 변수ì�´ë¦„, ë©”ì�¨ë“œì�´ë¦„ 사용, 코드 ì�¼ë¶€ë¶„ì�„ ì�˜ë¯¸ìžˆëŠ” ì�´ë¦„ì�˜ ë©”ì�¨ë“œë¡œ 추출 등) ì–´ë• ì�„까요? --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ê³¼
하지만, "확실히 ì„¤ëª…í• ë•Œ
난해한 코드ì�¼ìˆ˜ë¡� 주ì„�ì�´ 필요한 것ì�¼ê²ƒì�´ê³ (ë˜�는 ê·¸ 반대로 쉽게 알아볼 수 있ë�„ë¡� 짤 방법ì�„ 강구해야 한다면 억지쓰는 것ì�´ë ¤ë‚˜.) ê°œì�¸ì �으로 ì�½ì–´ë³¸ 가장 긴 ë‚¯ì„ ì½”ë“œê°€ 3000~4000 ë�¼ì�¸ì�„ 못넘어 본 관계로 ì•„ì§�ì�€ 'ì •ë¦¬' 단계로만 ë��ë‚ ê²ƒ 같다. CVS ì�˜ history ê°€ 코드 ì§„í™”ê³¼ì •ì�„ ë”°ë�¼ê°€ëŠ”ë�° ë�„움ì�„ 줄것ì�´ë�¼ê³ ìƒ�ê°�했지만, ì•„ì§�ì�€ 먼 ì�´ì•¼ê¸°ì�¼ë“¯. ~cpp JavaDocì�˜ 출발ì�€ 아예 다르다. ìž�네가 바란건 ë””ìž�ì�¸ 단위로 프로그래ë°�ì�„ ì�´í•´í•˜ê¸¸ ì›�한거 ê°™ì�€ë�°, 그것ì�„ ~cpp JavaDocì—�서 ë§�해주는건 ë¶ˆê°€ëŠ¥í•˜ë‹¤ê³ ìƒ�ê°�한다. Sunì—�서 msdnì—� 대ì�‘하기 위해(?) ~cpp JavaDocì�´ 태어난것 ê°™ì�€ë�° ë§�ì�´ë‹¤. 하지만, "확실히 ì„¤ëª…í• ë•Œ
~cpp JavaDoc뽑아서 ê·¸ê±°ê°€ì§€ê³ ì„¤ëª…í•˜ëŠ”ê²Œ 편하긴 편하ë�”ë�¼."ë�¼ê³ 한ë§� 풀어쓰는 ê±´ë�°, 만약 ë””ìž�ì�¸ ì�´í•´ 후ì—� 코드ì�˜ ì�´í•´ë�¼ë©´ ~cpp JavaDoc ì—†ê³ ì†ŒìŠ¤ë§Œìœ¼ë¡œ ì�´í•´ëŠ” 너무 ì–´ë µë‹¤.(최소한 나ì—�게는 그랬다.) ì�¼ë‹¨ 코드 ë¶„ì„�시 ~cpp JavaDocì�´ 나올 ì •ë�„ë�¼ë©´, "긴장 완화"ì�˜ 효과로 ë¨¹ê³ ë“¤ì–´ 간다. ê·¸ë¦¬ê³ ìš°ë¦¬ê°€ 코드를 ì�½ëŠ” 시ì �ì�€ jdk를 쓸때 ~cpp JavaDocì�„ ë³´ì§€ 소스를 보지는 않는 것처럼, 해당 메소드가 library처럼 ëŠ�껴지지 않ì�„까? 그것ì�´ 메소드ì�˜ ì�´ë¦„ì�´ë‚˜ 필드ì�˜ ì�´ë¦„만으로 완벽한 표현ì�€ ë¶ˆê°€ëŠ¥í•˜ë‹¤ê³ ìƒ�ê°�한다. 완벽히 표현했다면 너무나 심한 세분화가 ì•„ë‹�까? ì „ì—� ì •ë§� 난해한 소스를 ë¶„ì„�한 ì �ì�´ 있다. 그때ë�„ ê°€ë�” ë³´ì�´ëŠ” 실낱같ì�€ 주ì„�들ì�´ 너무나 ë�„움ì�´ ë�œê²ƒì�´ 기억난다. 우리가 ì œì¶œí•œ Report를 대학ì›� ìƒ�들ì�´ ë¶„ì„�í• ë•Œ ì—시 마찬가지 ì�¼ê²ƒì�´ë‹¤. ì�´ê±´ ê¶�ê·¹ì�˜ Refactoringë¬¸ì œê°€ 아니다. 프로그래ë°� 언어가 ê·¸ ì…°ì�µìŠ¤í”¼ì–´ 언어와 같았으면 하기ë�„ 하는 ìƒ�ê°�ì�„ 해본다. ìƒ�ê°�ì�˜ 언어를 프로그래ë°� 언어 ëŒ€ìž…í• ìˆ˜ë§Œ 있다면야.. --ìƒ�민내가 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)ê³¼
ê·¸ë¦¬ê³ ê³„ì†� ì�´ì•¼ê¸° 하다보니 주ì„�(comment)ê³¼
~cpp JavaDocì�„ 나누어 설명하는 것ì�´ 올바른 ìƒ�ê°�ì�¸ë“¯ 하다. 그런 ê´€ì �ì�´ë�¼ë©´ ì�´ë²ˆ 코딩ì�˜ 컨셉ì�´ 녹색글ìž� 최소주ì�˜ë¡œ ë‚˜ê°”ë‹¤ê³ ë³¼ìˆ˜ 있다. 머리ì†�으로는 특별히 둘ì�„ 나누지 ì•Šê³ ìžˆì—ˆëŠ”ë�°, 코딩 습관ì—�서는 ì™„ì „ížˆ ë‚˜ëˆ„ê³ ìžˆì—ˆë�˜ê±° 같다. 녹색 글ìž�를 ì“°ì§€ 않ì�„ë ¤ê³ ë°œì•…(?)ì�„ 했으니.. 그래ë�„ ë³´ì�´ëŠ” 녹색 글ìž�들 ë³´ë©´ 죄ì�˜ì‹�ì�´ ì�´ê²ƒì�´ object worldì—�서 ë§�하는 "프로그래머ì�˜ 죄ì�˜ì‹�"ì—� 해당하는 것ì�´ ì•„ë‹�까. --ìƒ�민재미있는 주ì„�
주ì„�ì�´ 실행ë� 수 있는 코드가 아니기 때문ì—�, 반드시 코드가 주ì„�대로 수행ë�œë‹¤ê³ ë³¼ 수는 없지만 없는것 보다는 낳ì�€ 경우ë�„ 많다. 코드 ìž�체는 언어ì�˜ 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ì�˜ ìž�ì‹�ì�¸)윗형 ...
우리는 충분히 ì�´ì„±ì �ì�´ê¸°ì—� 주ì„� ìž�ì²´ë§Œì�„ ë³´ê³ ëª¨ë“ ê²ƒì�„ ë¯¿ìœ¼ë ¤ê³ í• ë§Œí�¼ 어리ì„�지는 않다. 주ì„�ì�„ ë¨¼ì € ê±°ì³�ê°„ 사람ì�˜ 숨길로 ëŠ�ë�¼ê³ , 재미로 ëŠ�ë‚„ 수 있게 ë�˜ë©´ 코드 리뷰가 í•ìƒ� 지루하지는 않ì�„ 것ì�´ë‹¤.
코드 ìž�체로서 ì�˜ë¯¸ë¥¼ ì�´ì•¼ê¸°í• 수 있ë�„ë¡� ì�´ë¦„ì�„ 잘 짓는 것ì�€ 분명 중요하지만, ê·¸ì—� 못지 않게 코드를 ì�½ê³ 작성하는 주체가 사람임ì�„ ìƒ�ê°�í• ë•Œ 주ì„�ì�€ ì�´ë“¤ì�„ 위한 ìž‘ì�€ ë°°ë ¤ë�¼ í• ìˆ˜ 있다.
--ì�´ì„ ìš°









