'implementation patterns'에 해당되는 글 4건

  1. 2008/03/09 symmetry는 context에 따라서 달라진다. (8)
  2. 2008/01/03 Symmetry (15)
  3. 2007/12/10 patterns : Most programs follow a small set of laws (20)
  4. 2007/12/04 Local Variable (22)
symmetry는 지키는 것은 중요하다.

특히, 켄트벡의 implemtation patterns를 본 이후로는 더 신경을 써서 고려하고 있다.

얼마전 특정한 업무영역에서 symmetry를 지키기 위해서 내가 선택한 것이 있다.

조금 더 넓은 의미의 도메인 영역(context)으로 생각을 했더니, 내가 선택한것은 좋은 선택이 아니라는 것을 알았다.

지금 생각하는 project context에서는 맞는 선택이었는데, 바로 상위 context를 고려해보니 다른 분들의 생가과 선택이 잘못되지 않았다는 것을 알았다...이런...-.-

집에서 좀 쉬다가 보니, 격정적이었던 지난 주는 시간에 쫓겨서 일했다는 것을 깨달았다.

시간에 쫓기다가 보니 좁은 의미의 context를 생각하게 되었고, 스트레스만 받았던거 같다.

이번일을 계기로~ 한발짝 물러서서 좀더 거시적으로 보는 습관을 들여야겠다. 이게 말은 쉬운데, 잘안된다.

잘못된 선택의 댓가로 서비스 기능을 추가하려 한다. 
Posted by ologist

2008/01/03 09:08 Developer

Symmetry

add의 symmetry이름은 remove이다.

젠장! 내가 만들어낸 production code에 난 별생각없이 delete라는 이름을 더 많이 사용한거 같다.

remove와 delete는 미묘하게 의미가 틀리지만, 우리가 이해를 하기에 아주 나쁜 수준은 아니다.

하지만, 우리가 자바를 하면서 애용하는 collection메타포를 보면 add vs remove가 더 어울린다.

symmetry의 사전적인 의미는 무엇일까?

User inserted image

Identifying and clearly expressing symmetry makes code easier to read.
Implementation Patterns

Kent Beck / Addison-Wesley Professional


symmetry의 장점은 반을 이해하면 나머지 반을 이해하기 쉬워서 가독성이 좋아진다. 반대로 symmetry가 깨지면 대칭이 되는 코드를 이해하는데 혼란이 찾아온다. 내가 기대하지 않는 코드의 구현이 되어있기때문이다.

나는 refactoring을 할때 extract method를 자주 애용하는 편이다. 이 refactoring을 진행을 하다가 보면, 어디까지 extract를 할지 고민이 많이 된다.

이때 symmetry를 떠올리자. extract method를 해서 의도가 명확해져서 communication하기 좋은 코드로 발전을 한다면, 코드량이 조금 더 많아 지더라도  extract를 계속하자. extract를 할때는 symmetry를 떠올리면서 이름을 짓는 것이 중요하다.

구현상으로는 symmetry를 지키려 노력을 했지만, 이름에서 symmetry 역시 구현의 symmetry만큼 곰곰히 생각해야 한다.
Posted by ologist
켄트벡 엉아의 주옥같은 문구들....

Programs are read more often than they are written.

There is no such thing as "done". Much more investment will be spent modifying programs than developing them initially.

They are structured using a basic set of state and control flow concepts.

Readers need to understand programs in detail and in concept. Sometimes they move from detail to concept, sometimes from concept to detail.
Posted by ologist

2007/12/04 06:36 Developer

Local Variable

나는 메소드를 작성할 때 로컬 변수의 사용을 적게 하는 편이다.

메소드가 길어지면, 가독성이 떨어지기때문에 가능한 2개이상 쓰이지 않으면 로컬 변수는 쓰지 않는다.

하지만, 로컬변수를 써서 메소드가 길어지는 것을 감수할 수 있는 경우가 있다.

로컬변수의 변수명이 코드를 읽을 때 가독성을 도와주는 경우가 있기 때문이다.

kent beck의 implementation patterns(chapter6-STATE, P.51)에서 예제를 가져왔다.

int top = ...;
int left = ...;
int height = ...;
int bottom = ...;
return new Rectangle(top,left,height, width);

반드시 계산하는 로직이 아니더라도 로컬변수가 의미를 설명해줄수 있다.







이 내용을 보면서 드는 생각이 클래스 생성자의 파라미터의 이름을 잘 짓고, 객체를 생성하는 구현을 할때는 대부분 로컬 변수를 통해서 전달을 해주는 것이 좀더 가독성이 좋아질거라는 생각이 들었다.

내가 코드를 작성을 할때 자주 하는 스타일을 소개하자면,
이클립스에서는 사용할 클래스를 import를 하고 코드자동완성 키(ctrl+space)를 누르면 signature가 나오고 에러를 친구삼아 ctrl + 1을 통해서 로컬변수를 생성하면 위와 같은 코드를 좀더 편하게 생성할 수가 있다. 사실 나는 import조차도 ctrl+1을 통해서 한다.

Posted by ologist
이전버튼 1 이전버튼

블로그 이미지
ologist

공지사항

Yesterday171
Today54
Total34,797

달력

 « |  » 2012.02
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

최근에 받은 트랙백

글 보관함