Skip to main content

Responsive Design seminar - Kent Beck

http://agile.egloos.com/5087979

정말 오랫만에 세미나를 가서인지 첫 시간은... 잘 잤다. ㅜㅜ 다음은 기억에 남는 얘기들.

Responsive to

Constraints

Feedback from system, people or customers.

Step back

문제를 만났을 때 한발짝 뒤로 물러서서 바라봐라... 쉬운 예로 어떤 코드의 테스트를 작성하는데 구현하기가 너무 어렵다면 한발짝 뒤로 물러서서 애초에 코드의 설계가 잘못된건 아닌지 확인해봐야 한다. 켄트벡이 든 예는 회전문이었는데... 회전문의  throughput, latency, variance등의 조건을 모두 고려하여 설계하기는 불가능하다. 이때 한발짝 물러서서 왜 회전문이 개선되어야 하는지, 혹시 문밖에 있는 인기있는 커피점때문은 아닌지 보자... 만약 그렇다면 커피점을 문안으로 들여오자. 뭐 이런 얘기...

마침 같이 갔던 H씨가 코드가 바뀔때마다 깨지는 테스트때문에 고민하고 있었는데 한발짝 물러서서 꼭 테스트가 필요한지 확인해보고 지워버리라고 조언... ㅎㅎ

Retrospect

자신이 하는 일을 돌아보자. 왜 이렇게 했는지...

Goal

Steady flow of features.

Design - beneficially relating elements

설계란 element들간의 관계인데 서로에게 이롭게 만드는 것.

Ambiguity

최선의 설계가 무엇인지 모호할 때는 그대로 놔두는 것도 필요. 그대로 놔두면 코드는 점점 망가지며 스스로 해결책을 드러낼 수 있다.

Safe steps

위험하며 효율적인(빠른) 방법보다는 안전하며 덜 효율적인 방법을 선호. 물론 안전하며 덜 효율적인 방법을 빨리 사용할 수 있다.

Values
아직 명확하진 않지만... 예를 들면 simplicity, feedback, community

Patterns
대부분의 디자인 결정은 problem domain과 관계가 없고 실제론 컴퓨터에게 시키는 instruction들에 의해 결정되고, 같은 패턴들이 반복되더라.

시간 낭비를 방지한다.

Principles

Strategies
Can see? (a design what you want)
  • Leap - 한번에 구현. 위험하나 효율적
  • Parallel - 동시에 이전 설계와 새 설계를 지원하여 서서히 이전
Can't see?
  • Stepping stone - 이런게 있으면 설계가 쉬워지겠다고 생각하는 항목을 구현 (framework?)
  • Simplification - 문제의 쉬운 버전을 일단 설계하고 얻은 경험을 바탕으로 서서히 원래 문제를 해결
Or
  • Add it anyway
  • Expect to pay the price later - 나중에 문제가 커지면 스스로 해결책을 드러낼 수도...
Coupling and cohesion
  • Coupling - 어떤 element 변경시 다른 element들이 변경될 확률. Hidden coupling은 발견하기가 매우 어렵다.
  • Cohesion - 어떤 sub-element 변경시 다른 sub-element들이 변경될 확률. Coupling보다 추적이 용이하다.
Refactoring
  • Bi-directional
  • Isolate change (Coupling and cohesion) - Cohesion이 높은 element로 extract한 후 변경
  • Interface or implementation - 동시에 interface와 implementation을 변경하지 않는다.
Succession
Succession of vegetative communities.

Data

Design is an island
  • No "best" design - 최선의 디자인은 없다.
  • Improvement
  • Deterioration
  • Sea level
  • Change in basis
Observations
  • Power laws
  • Fractal - 같은 패턴이 여러 규모의 구조에서 발견된다.
  • Symmetry - 예를 들어 4개의 member field들 중 하나만 다른 행동을 한다면 그 클래스에 속하지 않는 녀석이 아닐까?
  • Punctuated equilibrium
이외에 설계시 social 입장을 고려해야 한다는 얘기도 있었다. 좋은 설계이나 팀원들이 이해할 수 없거나 아직 받아들이기 힘든 경우도 고려해야 한다는 얘기였던 듯...

추가

http://www.infoq.com/presentations/responsive-design에서 거의 같은 내용을 볼 수 있네요.

발표 자료는 http://agile.egloos.com/5106266에 있습니다.
Labels:

Comments

  1. z1h0September 5, 2009 at 5:07 AM

    이것은.. 거의 2년만에 올라온 새 포스팅이군요! 혹시 입사 후 첫 포스팅은 아니신지? :)

    ReplyDelete
  2. iwonguSeptember 5, 2009 at 8:01 AM

    아흑.. 맞아요.
    근데 다음은 또 언제일지... ㅎㅎ

    ReplyDelete
  3. mkseoSeptember 8, 2009 at 2:21 PM

    포스팅 정말 오랜만입니다. 어제오늘 사이의 테마 변경사항도 눈여겨 보고 있습니다. ㅎㅎ 미니멀리즘 테마라니, 제가 정말 좋아하는 디자인이군요.

    ReplyDelete
  4. A History of CLU « IdeA thinKING v3September 16, 2009 at 4:44 AM

    [...] 글을 읽고나니 Kent Beck이 세미나에서 언급했던 Structured Design이라는 책이 읽고 싶어지네요. Kent Beck도 이 [...]

    ReplyDelete
  5. Valuing Ambiguity « IdeA thinKING v3September 17, 2009 at 2:23 AM

    [...] Kent Beck 세미나에서 언급됐던 Valuing Ambiguity에 대한 내용이 Kent Beck의 블로그에 [...]

    ReplyDelete

Post a Comment

Popular posts from this blog

1의 개수 세기 - 해답

벌써 어제 말한 내일이 되었는데 답을 주신 분이 아무도 없어서 좀 뻘쭘하네요. :-P 그리고 어제 문제에 O(1)이라고 적었는데 엄밀히 얘기하자면 O(log 10 n)이라고 적었어야 했네요. 죄송합니다. ... 문제를 잠시 생각해보면 1~n까지의 수들 중 1의 개수를 얻기 위해서는 해당 숫자 n의 각 자리의 1의 개수가 모두 몇개나 될지를 구해서 더하면 된다는 사실을 알 수 있습니다. 예를 들어 13이라는 수를 생각해 보면 1~13까지의 수에서 1의 자리에는 1이 모두 몇개나 되는지와 10의 자리에는 모두 몇개나 되는지를 구해 이 값을 더하면 됩니다. 먼저 1의 자리를 생각해 보면 1, 11의 두 개가 있으며 10의 자리의 경우, 10, 11, 12, 13의 네 개가 있습니다. 따라서 2+4=6이라는 값을 구할 수 있습니다. 이번엔 234라는 수에서 10의 자리를 예로 들어 살펴 보겠습니다. 1~234라는 수들 중 10의 자리에 1이 들어가는 수는 10, 11, ..., 19, 110, 111, ... 119, 210, 211, ..., 219들로 모두 30개가 있음을 알 수 있습니다. 이 규칙들을 보면 해당 자리수의 1의 개수를 구하는 공식을 만들 수 있습니다. 234의 10의 자리에 해당하는 1의 개수는 ((234/100)+1)*10이 됩니다. 여기서 +1은 해당 자리수의 수가 0이 아닌 경우에만 더해집니다. 예를 들어 204라면 ((204/100)+0)*10으로 30개가 아닌 20개가 됩니다. 이런 방식으로 234의 각 자리수의 1의 개수를 구하면 1의 자리에 해당하는 1의 개수는 ((234/10)+1)*1=24개가 되고 100의 자리에 해당하는 개수는 ((234/1000)+1)*100=100이 됩니다. 이들 세 수를 모두 합하면 24+30+100=154개가 됩니다. 한가지 추가로 생각해야 할 점은 제일 큰 자리의 수가 1인 경우 위의 공식이 아닌 다른 공식이 필요하다는 점입니다. 예를 들어 123에서 100의 자리에 해당하는 1의 개수는 ((123/1...
3 comments
Read more

CodeHighlighter plugin test page.

This post is for testing CodeHighlighter plugin which uses GeSHi as a fontifier engine. ((Those code blocks are acquired from Google Code Search .)) ((For more supported languages, go CodeHighlighter plugin or GeSHi homepage.)) C++ (<pre lang="cpp" lineno="1">) class nsScannerBufferList { public: /** * Buffer objects are directly followed by a data segment. The start * of the data segment is determined by increment the |this| pointer * by 1 unit. */ class Buffer : public PRCList { public: Buffer() { ++index_; } PHP (<pre lang="php" lineno="4">) for ($i = 0; $i $value = ord( $utf8_string[ $i ] ); if ( $value < 128 ) { // ASCII $unicode .= chr($value); } else { if ( count( $values ) == 0 ) { $num_octets = ( $value } $values[] = $value; Lisp (<pre lang="lisp">) ;;; Assignment (define-caller-pattern setq ((:star var fo...
88 comments
Read more

Coverity Prevent - 소스 코드 검사 도구

이번에 회사에서 소스 코드 검사 도구를 하나 구입하는데 이것저것 비교해본 결과 Coverity Prevent 라는 툴이 가장 좋아 이걸로 결정했다고 하더군요. 간단히 말하자면 Lint 처럼 소스 코드에 대해 static analysis를 하는 도구입니다. 그래서 시험삼아 돌려본 결과를 보게 되었는데 그 품질이 정말 놀랍군요. 메모리 릭이나 초기화하지 않은 변수, 버퍼 오버런, null 체크등등 거의 정확하게 에러를 보고해 줍니다. 다음은 전체 코드에서 발견된 문제점들을 리스트 형태로 보여주는 화면입니다. 정말 많군요. ;-) 다음은 이중 하나의 에러를 자세히 보기 위해 선택하여 들어간 화면입니다. 소스 코드에 라인번호와 에러가 발생한 위치, 에러가 발생할 수 있는 조건들을 자세히 보여줍니다. 정말 '와우!'입니다. 각 함수와 같은 이름들을 클릭하면 그 함수로 바로 이동할 수 있습니다. 사용해보니 개인적으로는 purify 같은 runtime 검사 도구보다 더 맘에 드는군요. 사실 Lint 계열의 도구들은 한번도 사용해본 적이 없는데 다른 것들도 한번 구해다 써봐야겠습니다. 이 툴의 유일한 문제는 비싸다는 것이랍니다. :-)
5 comments
Read more