Dreamjr.ORG

4pm, 7:38pm 23:42, 3:16, 3:16am 등의 시간 표현을 모두 받아들일 수 있는 BNF 문법 설계

<Time> ::== <24Hour><ampm> | <12Hour>:<Minute><ampm> | <24Hour>:<Minute> | <12Hour>:<Minute><ampm>

<24Hour> ::== <decimaldigit> | <24hdecimaldigit><decimaldigit>
<12Hour> ::== <decimaldigit> | 1<decimaldigit>
<ampm> ::== am | pm
<Minute> ::== <1to5decimaldigit> <decimaldigit> | <decimaldigit>
<decimaldigit> ::== 0|1|2|3|4|5|6|7|8|9
<24hdecimaldigit> ::== 1|2
<1to5decimaldigit> ::== 1|2|3|4|5

실용주의 프로그래머 119페이지 연습문제 6번에 대한 답을 적었음. 해설에 나와있는 것을 조금 보완했는데 정확한지는 ^^;

Design patterns 책을 읽다가 Observer pattern 이란 것에 대해 알게 되었다.

한 객체의 변화를 다른 객체에도 전파할 수 있는 방법인데, 보다 느슨한 결합을 가능하게 해 주는 방법이라고 한다.

java.util.Observable 클래스와 java.util.Observer 인터페이스를 사용해서 구현하는 방법이 있고,

Observable 클래스(를 상속한 클래스)에서 setChanged() 함수를 사용하여 객체 변화 상황을 세팅하고, notifyObservers() 메소드를 통해 변화가 있음을 알리면 Observer 인터페이스를 구현한 클래스의 update() 메소드가 실행되는 구조인 것 같다.

컴포넌트에 이벤트 리스너를 등록하는 JavaBeans 컴포넌트 모델을 따르는 방법도 있다고 한다.

추후 필요한 경우에 더 보도록 해야 되겠다.

Refactoring 책 213 page (http://dreamjr.org/tt/index.php?pl=73&ct1=7 참고) 또는
http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf 문서의 3페이지에 보면 black diamond가 나온다.
(회사라서 이미지 첨부를 할 수 없음)

이 black diamond는 Composition relationship을 표현하는 UML 기호이다.

나온 그림의 의미는, 화살표 왼쪽에 있는 객체 인스턴스가 가 오른쪽에 있는 객체의 인스턴스를 포함하고 있고(즉, 왼쪽에 있는 객체는 오른쪽에 있는 객체(들)로 구성(compose)되고), 오른쪽에 있는 객체는 왼쪽에 있는 객체를 전혀 모르는 경우를 말한다.

첨언하자면 black diamomd는 composition 관계를 뜻하고, 화살표 방향이 한방향인 것은 relationship이 한 방향으로만 navigable 하다는 의미(즉 화살표 오른쪽의 객체는 왼쪽의 객체를 전혀 모르는)를 나타낸다.

Composition relationship은 aggregation relationship(속이 텅 빈 다이아몬드의 형태로 표현되는)의 매우 강한 형태라고 할 수 있다.

Refactoring 책에서 Delegation 관련 내용이 나와서 궁금하여 찾아보았다.

위임(Delegation)이란, 어떤 메소드의 처리를 다른 인스턴스의 메소드에 맡기는 것이다.

상속의 경우, class형이 정적으로 정해지기 때문에, 다른 자료형이 필요해진다면 프로그램의 구조 자체를 몽땅 수정해야 하는 단점이 있다. 위임(Delegation)은, 보다 유연하고 손쉽게 새로운 자료형을 추가/새로운 자료형으로의 변환 등을 할 수 있다는 장점이 있다.

위키피디아 에 있는 Delegation pattern 의 정의는 다음과 같다 :
In software engineering, the delegation pattern is a technique where an object outwardly expresses certain behaviour but in reality delegates responsibility for implementing that behavior to an associated object in an Inversion of Responsibility. The delegation pattern is the fundamental abstraction that underpins composition (also referred to as aggregation), mixins and aspects.
--> 대략의 뜻은, "delegation pattern은 외부 object가 어떠한 행위를 표현하지만 실제로는 그 행위를 구현하기 위한 책임을 관련된 object에 위임(delegation)한다." 이다.

역시 위키피디아에서 긁어 온 java 예제는 다음과 같다.

class A {
void f() { System.out.println("A: doing f()"); }
void g() { System.out.println("A: doing g()"); }
}

class C {
// delegation
A a = new A();

void f() { a.f(); }
void g() { a.g(); }

// normal attributes
X x = new X();
void y() { /* do stuff */ }
}

public class Main {
public static void main(String[] args) {
C c = new C();
c.f();
c.g();
}
}

==> Class C 가 실제 행위를 하는 것처럼 보이지만 실제 구현은 Class A에 되어 있다.

참고 URL : http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=267290&CategoryNumber=001001003005006

넥슨에서 근무하며 게임 포털 사이트를 만들고 있을 때, 선배 개발자 형으로부터 한 책을 추천받았다. '리팩토링' 이라는 책이었으며, 간단하게 '리팩토링이란 소스를 다듬는 것이다...' 라고 들었던 것을 기억한다.

이 당시 Java로 커뮤니티 사이트(http://club.nexon.com)를 만들고 있었다. 개발 초창기에 다른 사람(알바)이 한달 정도 끄적거리던 소스를 넘겨받아 보았더니 JSP 파일에 DB 커넥션 하는 부분 및 business 로직까지 몽창 다 들어있던...소싯적 ASP 하던 때와 똑같은 분위기로 코딩되어 있던 것을 보고 경악했던 기억이 있다 -_-. 결국 DB 로직은 따로 빼고, business 로직 부분은 좀 귀찮아서(일정도 있고, 이런 저런 핑계로) 일부은 따로 뺐지만 일부는 걍 JSP 파일에 남겨두었던 것 같다. 다른 사람에 의해 구현되었던 부분이 별로 없었기에 가능했던 일이었을 지도 모르겠다.

암튼 사정이 이러다 보니 다듬는다고 다듬었는데 소스도 꽤 지저분하고, 개념도 덜 탑재되어 있던 상황이라서 소스는 중복에 중복 투성이(문자열 인코딩하는 부분의 소스가 특히 아주 지저분했던 것 같다. 만들었던 메소드 또 만들고 또 만들고 이름만 바꿔 추가하고 등등 -_-;) 였던 것 같다. 그럼에도 불구하고 나름대로 회사 다니면서 학교를 다니던 상황이라서 시간이 빡빡했던 것도 사실이었고(지하철에서 예습복습하고 회사에 늦게 가서 11시 넘어 퇴근하고 다음날 아침에 또 학교가는 생활의 연속 ㅠㅠ) 이러 저러한 핑계로 그 형의 제안을 묵살 아닌 묵살을 해 버리고 말았다.

LG전자에 들어와서 임베디드 S/W 개발자로 커리어 패스를 전환한 후에 이런 저런 스펙(WAP, MMS 관련) 스터디도 하고, XP 관련 세미나도 기웃거리고 하면서 느낀 점은 내가 전에 웹 개발을 하면서 너무 기본을 소홀히 하고 구현에만 급급했다는 생각이었다. 웹 개발자가 웹 스펙조차 본 적이 없었다는 점과 소스 리뷰를 소홀히 했다는 생각이 나를 자책하게 만들었다.

그래서 예전 선배 형에게 심정적인 사죄도 하고, 새로 옮길 팀에서도 리팩토링을 수행하고 있다고 하기에 대비도 할 겸 겸사겸사 책을 구해서 읽게 되었다.

서두가 너무 길었다.

책 내용은 리팩토링을 예제를 들어서 설명하고, 리팩토링의 원리에 대해서 간단히 설명한 후, 리팩토링을 해야 할 징후가 나타나는 코드 속의 징후에 대해 설명한 후에, 리팩토링 시 반드시 필요한 TDD 에서도 사용되는 자동 테스트 프레임워크인 JUnit에 대해 설명한 후, 여러 리팩토링 카탈로그(리팩토링 방법을 사전식으로 죽 나열한 것)에 대한 설명과 예제 나열로 구성되어 있다.

리팩토링을 간단하게 말하면 '코드 정리' 이겠지만, 보다 중요한 개념은 '코드의 의미 명확화' 이다. 저자는 코드 자체가 주석을 필요로 하지 않아도 될 정도로 의미가 명확하게 되는 것을 궁극적인 목적으로 하고 있다. '6. 메소드 정리' 의 내용을 보자면, 긴 메소드에서 짧은 메소드로 추출해 낼 때에도, 아무렇게나 추출하지 않고 적절한 기능을 가진 코드 라인을 그 기능에 걸맞는 명확한 이름을 부여하여 추출해 내야 한다고 말하고 있다. 코드에 임시 지역 변수가 남발되는 것 또한 경계하고 있는데 그렇게 되면 지역 변수가 어떤 역할을 하는지 의미가 모호해져 코드를 분석할 수 없게 되기 때문이다.

JUnit에 대한 설명이 나와 있는 것을 보고 알 수 있듯이, 리팩토링 또한 XP 방법론이 따라가는 철학의 일부라는 생각이 든다. 리팩토링을 완전무결한 Design을 통한 S/W 개발이 아니라, Design은 어느 정도만 하고 추가할 점이 발견되면 그때 그때 개선하는 S/W 개발 방법론(?)을 보조하기 위한 필수 단계로 설정해 놓은 점이 이채롭다.

리팩토링은 퍼포먼스 튜닝과는 대비되는 개념이지만, 퍼포먼스 튜닝을 보조할 수 있는 수단이라는 점도 흥미로왔다. 소스를 정리하고, 복잡한 메소드를 나누며, 복잡한 클래스를 서브클래싱 하는 등 소스를 리팩토링 하게 되면 인스턴스를 많이 생성하게 되는 등 퍼포먼스가 일시적으로는 떨어질 수 있지만, 리팩토링이 완성된 후에는 소스를 이해하기 쉬워지고 퍼포먼스 튜닝하기도 용이해지므로 우선 리팩토링을 한 후에 퍼포먼스 튜닝을 하라는 내용이 정말 공감이 갔다.
사실, 디버깅이나 튜닝이나 실제 디버깅 or 튜닝하는데 드는 시간보다는 디버깅 or 튜닝을 해야 하는 곳을 찾는데 시간이 90% 이상 드는 것이 사실이다. (현재 Trace32 같은 디버거도 없이 폰에 생긴 버그를 수정해야 하는 상황에 있는데 미쳐 버릴 것 같은 것이 현실이다. 더군다나 지금 쓰는 GSM 솔루션은 매우 지저분해서 하나의 함수가 1000 라인이 넘어가는 경우도 허다하다 -_-) 리팩토링은 그 찾는 시간을 줄여줄 수 있는 좋은 수단이 될 수 있을 것 같다.


팀을 무사히 옮기게 되면, 옮긴 팀에서는 리팩토링, TDD 등을 사용해 볼 수 있을 것 같기도 하다. 구슬이 서말이라도 꿰어야 보배라고...실무에 적용해 보고 이 내용에 깊이 공감해 볼 수 있게 되기를 바란다. 리팩토링은 현재 만들어 지고 있는 이론이고, 전산학의 전공 필수 과목처럼 정착된 분야가 아니기 때문에 책 내용은 따분한 이론의 나열이 아닌, 저자의 경험 중심으로 이해하기 쉽고 재미있게 되어 있다. 한 번 읽어 보면 소스 리팩토링할 때에는 물론 코드를 작성할 때의 나쁜 버릇을 고치는 데에도 도움이 많이 될 것 같다.

1. 신제용 선임님께 추천받은 개인위키..

http://jeyong.com

2. 그리고, 위키 설치 가이드 - 집에 가서 cafe24 hosting에 올려서 사용해 볼 예정임...

http://blog.naver.com/sunkwarch?Redirect=Log&logNo=60021202950

3. 위키 설치 후에(혹은 설치 중에) 할 일들

[1]. 엑셀을 이용하여 시간 관리 툴(QV와 비슷한)을 만든다
* 만들기 전에 간단하게 스토리를 짜 본다(XP 간략 실습)

[2]. 엑셀 add-on 프로그램으로 짜 본다
* 기술적 검색(하는 방법 및 필요한 책 검색)
* 스토리를 짜 보고 XP 방법론으로 진행해 본다
* 6sigma에 적용할 수 있는지 확인

[3]. [1] 또는 [2]를 사용하여 오전8시~오후 5시 까지의 작업, 스터디 및 휴식 패턴 기록...효율성 높이기
* 6sigman에 적용할 수 있는지 확인
* 개인 위키에 업뎃해보기

[4]. 위키의 정신 및 활용 방법에 대한 숙지...
* from jeyong.com


- 블로그가 위키 체로 바뀐 듯..ㅋㅋㅋ

-괜찮은 책인듯..
http://blog.naver.com/keidao?Redirect=Log&logNo=140020746380

-eXtreme Programming 사이트
http://xper.org/wiki/xp/

- XP에 대한 자세한 설명
http://blog.naver.com/graysun0?Redirect=Log&logNo=100021320654

우선 clipping 해둠...