2009/09/04: 켄트 벡 세미나 후기 - 반응적 설계

kent_rd.txt

2009/09/04: 켄트 벡 세미나 후기 - 반응적 설계


Kent Beck 방한 세미나
Responsive Design

세미나 기록 by 종텐(Jong10)



(주의사항)

1. 이 자료를 너무 믿진 마세요. 못 들은 부분이나, 잘못 쓴 부분이 있을수 있어요.
2. 실제 강의자료와 같이 보시면 좋을 것 같네요. http://drop.io/responsive/asset/responsive-design-one-day-ppt
3. 정리를 못해서, 그냥 통째로 올려요. 정리하고 싶었는데...


/////////////////////////////////////////////////////
/////////////////////////////////////////////////////
/////////////////////////////////////////////////////
/////////////////////////////////////////////////////
/////////////////////////////////////////////////////


진행자 왈, 오늘 세미나에서 insight를 가져갈 수 있길.


리차드 ?? 심리학 교수
사고의 지형?

동양 사람과 서양 사람들간에 사고방식의 차이

셋중에 관련 없는 것 : 강아지, 소, 풀

서양 : 풀 - 포유류
동양 : 강아지 - 소가 무엇을 할 수 있느냐는 면에서, 맥락적.

달팽이 그림을 그려놓으면, 통계적으로 차이가 있을만큼 걸음속도가 느려짐
인지하지 못하지만.

아들의 두가지 질문.
다양한 사고를 가질 필요가 있겠다.

--------------------------------------

켄트벡 키워드

1. 개발자가 작성하는 테스트
2. 패턴
3. 익스트림 프로그래밍

켄트벡이 자신의 인생에서 소프트웨어 개발에 가장 큰 영향을 끼친 것 3가지.


김창준님이 고른 키워드 두가지.
1. 개발자가 작성하는 테스트. xUnit family. -> smalltalk에서 만들었고, 에릭 감마와 JUnit로 옮겼음. -> 몇백개의 언어로 퍼지게 됨.
요즘은, 언어 고르는 기준 중 하나가, 유닛테스트 프레임웍이 잘 지원되는지?
개발자가 자동화된 테스트를 작성한다는 사실이 많이 퍼졌음.
Test Impacted. xUnit의 코드를 소개하는..
엄청나게 높은 ROI.

2. 패턴
패턴의 진정한 선구자. GoF보다도.
1987년, OOPSLA, 패턴에 대한 논문.
켄트벡이 대학원생이었을때, 서점에 갔는데, The Timeless Way of Building. 건물을 짓는 영구적인 방법.
서점에서 서서 한달동안 책을 다 봤음.
굉장한 충격을 받았다. 건축계의 정치학을 뒤집어버렸다.
크리스토퍼 알렉산더, 건축에서 행해지는 실천법이 잘못 되었다.
건물에서 살게 될 사람과, 건물을 만드는 사람간의 관계에서 간극이 존재한다.
현대화라는 것 자체가, 생산자와 소비자를 멀리 떨어뜨려놓는것.
크리스토퍼 알렉산더가 조사해보니, 그런 집에서 사는 사람들은 별로 행복하지 않은 것 같더라.
행복한데서 사는 사람들의 집은 공통점이 있음.

어떤 상황(Context)에 어떤 문제(Problem)이 있고..
거주자들이 패턴을 고를 수 있게 되었다.
소프트웨어에서도, 패턴이 있으면, 사용자와 커뮤니케이션이 가능할 것 같다.
맨 처음 만든 패턴은 UI패턴이었다. 템플릿 패턴이 아니고.
켄트벡이 중요하게 생각한 것은, 생성자와 소비자를 연결하는 것.
회사에 적용했더니, 사람들이 좋아하더라.


GoF책을 한번에 이해한 사람은 별로 없음.
이해하려면, 경험이 굉장히 많아야 되고, 고민도 해봤어야 한다.

Design Patterns Smalltalk Companion -> GoF와 달리, 스몰토크가 잘 활용되서 코드가 확 짧게, 한 입에 넣을 수 있을만큼 이해하기 쉽게 되어있다.
SDPT -> (자바버전) 구현패턴

GoF -> 명사, 동사
켄트벡 -> 관사, 대명사
..처럼 느껴짐.


상황에 따라서 내가 만든 패턴들을 추려내서 활용한다.
정형화되서 고정되면, 그건 아니다.

내면화 작업, 성찰 작업.

------------------------

켄트벡의 아이디어를 관통하는 핵심.

1. 단순성에 대한 집착.
새로운 아이디어를 만들어내는 공식. (김창준이 10년 넘게 지켜본 바)
터무니없는 아이디어를 생각한 후에, 극단적인 경우에 적용해보는 실험을 많이 했다.
TDD, XP, User Story 등도 이런 식으로 나왔다.
표면적으론 간단하고 멍청한 아이디어지만, 내면적으로는 깊이가 있다.
User Story는 불필요한 detail을 생략하는 것이 포인트.
다 적혀있으면, 대화를 하지 않게 됨.
대화를 하게 만드는 사회적인 효과가 있다.

2. 인간적인 성숙을 위한 노력.
인간적인 성숙을 위해 노력을 많이 한다.
자극을 많이 받는다.

-------------------------






컨퍼런스
열린 괄호와 닫힌 괄호.
닫힌 괄호 : 듣고 나면, 아하~ 하면서 끝나는 것.
열린 괄호 : 듣고 나면, 질문이 생긴다. 몇가지를 실험해보고 싶어짐.





-------------------------

===========================================================

(켄트벡 등장!)


최근에 제가 하고 있는 작업,
Software design에 대한 작업을 소개해 드릴 수 있어서 반갑다.

제가 프로그래밍을 해온게, 30년 정도.
그런데 제가 프로그래밍 시작하고 얼마 안되었을때,
software design을 할 수 있었다.

누가 제게 와서, 문제가 있다. software 이거는 어떻게 디자인 해야되냐고 하고,
나는 이런 식으로 디자인한다.
그런데, what과 why는 차이가 있다.

다른 사람에게 설명을 할 수 있다는 것은, 이렇게 하면 될 것 같다는 것과 다르다.

어떤 때는 잘하고, 어떤때는 안되고,

그리고 3년전 정도에, OOPSLA 회의에 참여해달라는 요청을 받았다.

"Structured Design" <- 책

제가 대학에 잇을때, 이 책을 교과서로 읽었다.
오래된 책이다.

읽으면 읽을수록 더욱 더 흥분이 되었다.
디자인에 대한 생각들, 패턴 작업을 해왔었는데, 리팩토링도.
비슷한 주제에 대한 작업을 해왔엇다.

근데, 이 책 안에, 근본적인 규칙들을 발견했다. 소프트웨어 디자인에 대한.

이 책에서 coupling, coherence에 대한 용어가 처음 사용되었다.

명확하게 소프트웨어 디자인을 설명하고 있다.
저자들과 대화를 나누면서,

여기 나와있는 주제를 업데이트 시켜서, 확장하고,
제 아이디어까지 포함해서, 커뮤니티에 발표를 하자는 생각을 했다.

목표는,
내가 소프트웨어 디자인을 할 때에, 내가 어떻게 하는지 이해를 해야 한다. 그래야 설명 하므로.
다른 개발자들에게도 커뮤니케이션을 하자.
디자인이 왜 중요하냐?
소프트웨어 개발에 있어서 많은 문제들이, 표면상의 symtom들이 예를 들어 testing
이는 사실 심층적으로 보면, 디자인상의 문제다.

테스팅 문제가 복잡하다 어렵다라고 생각할 수 있는 상황이면,
복잡한 테스팅 툴을 만들어서 해결하자고 하지만,
사실은 디자인 문제이다.

테스팅 문제만 생겼다는 것을 보고, 테스팅 문제로만 다루게 되면, 결국은 소프트웨어 개발자로서 내 일이 더 힘들어진다.


소프트웨어 개발의 다른 문제들에 있어서도,
같은 파일을 수정하는, 팀워크 문제도 사실,
왜 같은 파일을 바꿔야 하는건지?
"근본적인" 문제는 디자인.
개발자로서의 일이 더 쉬워진다.
물론, 디자인 자체는 어려워질 수 있다.

올바른 디자인을 찾는데 더 어렵겠지만, 소프트웨어 개발을 더 쉽게 만든다.

C++ 작업에, 빌드에 하루 이상 걸리는 분?
이 빌드 타임을 가지고, 문제라고 보면, 세련된 툴,하드웨어를 구입할 수 있지만,
코드를 더 작은 조각으로 분리할 수 있고,

디자인이 생각할만한 가치가 있다.

////////////////////////////////////////////////////

소프트웨어 디자인을 연구할 땐 이렇게 한다.

1. introspection. 내재성.
많은 프로그래밍을 하고, 노트 태깅을 한다.
이걸 시도했는데 안됏다.
어제 이걸 해봤는데, 이건 비슷하네. 패턴이 있는가?
관찰. 이 첫번째..

2. 경험적.
다양한 여러 소프트웨어를 그냥 보는 것.
소프트웨어를 보면서, 실용성을 찾아내는 것.
미학적인 측면도 본다.
디자인으로서 미학적인 면이 굉장히 중요하다.
소프트웨어에서 아름다움을 경험해야 한다.
제대로 디자인 안 되었을때 이건 진짜 안좋구나를 경험해야 한다.
이건 진짜 아니다라고 했을때, 이걸 변화하기 위한 에너지가 생긴다.
이걸 찾아내지 못하고, 개선의 필요성을 못 느끼면,
그렇지 않으면, 개발자로서의 생명이 끝난 것이다.

3. 정량성.
여러가지 매트릭스가 있는데,
디자인을 매트릭스를 이용해 분석을 시작했을때,
제가 기대하지 않았던, 패턴을 볼 수 있게 되었다.
매트릭스엔 이렇게 되어있는데, 숫자는 다르다는 것이다.

소프트웨어에 있어서는 이 부분이 가장 심오한 부분이다.
소프트웨어 디자인은 결국은 "합리적인 과정"이 아니다는 것이다.
우리가 디자인한다고 생각하지만 그게 아니다.
책임성을 유지하는 것, 과정의 학습??, 과정에 대한 컨트롤 하는 것을 포기한다고 생각하는 것 자체가,
자신에게도 도전이고, 디벨로퍼에게도 얘기하는 것이다.

Why now?
소프트웨어에 대해 생각하는 시기가 지금이 적기인가?
중요한 변화가 일어나고 있다.
우리가 의존해왔던 디자인, 이용했던 패턴, 이용했던 습관들.
여태껏 먹혔던게 더 이상 아니다.

이미 더 잘 알고 있는 것을 디자인하는 것 뿐 아니라,
next generation을 디자인할 수 있는 스킬이 있어야 한다.
즉, 소프트웨어를 변화를 유도하는 이런 변화 때문.
예를 들어, C컴파일러를 디자인 한다. 흥미로울 수도 있지만, 여러분들의 C컴파일러 디자인은 다른분이 하는 것보다 더 나을 수도 있다.
하지만, 훨~~~~~씬 더 좋지는 않다. 컴파일러 기술은 그렇게 빨리 변하지 않기 때문.
디자인할 수 있는 능력은, 상황이 빠르게 변할때 잘 나타난다.

중요한 변화는..
- 무어의 법칙이 끝났다. End of free Moore's Law
기다리면서 성능 문제를 해결 할 수 있었는데, 이젠 안 그럼.
성능증가에 중독이 되어있다.
기다리면서 성능이 "훨씬 더 좋은" 머신이 나오기 어렵다.
그래픽에선 멀티플 코어를 마련하는 방법이 나왔지만,
모든 소프트웨어에 적용되는건 아니다.
성능에 대한 recomment.
이에 대응하기 위한 디자인.

- Scale
아마존, 구글, 야후 등등의 선도적인 업체들이,
디자인에 있어서 새로운 아이디어를 넣었다.
MapReduce 패러다임은 매우 좋은 디자인이다.
왜냐면, 프로그래밍 모델에서 원하는 것을 많이 간소화 시켰다.
이러한 혁신이 수백개가 나와야 한다.

- Cloud
과거엔 쉬웠던 것들이 어려워지고, 어려웠던 것들이 쉬워진다.
클라우드에 있는 리소스를 이용하게 되고, 문제를 피할 수 밖에 없다.

- Re-client
20년전: 프로그램이 멋져야 한다.
??년전: 프로그램을 서버사이드로.. but, 유저들은 ugly interface
하지만 이제 클라이언트가 점점 더 커지고 있다.

클라이언트가 크고, 서버가 클 경우에, 소프트웨어를 디자인하긴 쉽지 않다.

기계를 이용하는 사람은 반응적인 프로그램이 필ㅇ하다.

프로그래머는 여전히 그걸 디자인하는 걸 잘 모르고,
경제적으로, 지속 가능하게, 신뢰성 있게,
디자인은 그걸 해결할 돌파구.

그래서, "지금" 소프트웨어 디자인에 초점을 맞춰야 한다.

/////////////////////////////////////////////////////////////

프로그래밍을 처음 배울때,
goal은 특정한 날짜에, 모든 기능을 다 갖춰야 한다.
..라고 배웠다.

1972년에 출간된 책.
delivery를 어떻게 하는지에 대한 내용이 있었다.
3개의 패러그래프. 유지보수랑 관련된.

처음 10%에만 디자인을 하고 있었다. 72년도엔.

근데, 아직까지도 50주에 기능 50개를 하는 프로젝트가 있다.

내가 비즈니스를 할 때에, 이것은 정말 나쁜 아이디어라고 생각할수밖에 없다.
(waterfall에 대해 얘기하는듯)


건물.
처음 설계에 5천불을 투자하는데,
모든 도면이 다 바뀔 수 있다.
소프트웨어도 모든게 바뀐다.
테크놀러지도, 고객도, 비즈니스 모델도, 바뀐다.
한가지 보장받을 수 있는것은,
10년후에는 똑같은 디자인이 아닐 것이다.

그런 불확실성을 위해서, 디자인을 꾸준히 도입해야 한다.






디자인이 완벽히 잘 되는 경우도 있지만,
잘 되지 않는 경우도 있다.

그런 경우는 결정을 내릴 때가 된다.


전략은 여러가지다.
어떤 경우는 디자인을 바꿔서 기능을 추가해야 한다.
추한 변화를 가해야 하는 경우가 있을수도 있다??


기능은 이렇고, 추한 방법이 보이고,
디자인을 바꿔서, 이게 아주 잘 들어맞는 것은 보이지 않는다.
그런 상황에서는, 이 기능을 다시 한번 재검토 한다.

"이게 과연 필요한지? 지금 이게 필요한지? 이게 왜 어려운지?"

고객과 다시 얘기를 하자. 이렇게 대화를 나누려고 생각한다.
또는 그 feature를 버릴 수도 있다.

어떤 경우는, 고무장갑과 긴 장화를 신고,
아주 추한 기능을 구현을 한다.
그러면 반드시 댓가를 치룬다.
그렇지만, 그 기능은 포함이 된다.

디자인이 좀 더 나빠졌고, 흉해졌지만,
그 다음 기능은.. 더 흉해진다. 그럴 경우는 시간에 맞춰서, 완성을 못할 경우도 있다.
조금 더 디자인을 해서 다시 자기 속도를 되돌릴 수 있겠지만,


내가 디자인할때 갖고 있는 목표는,
기능을 추가할때 직선적으로 하자. 아니면 다시 재고를.
또 다른 방법으로 검토를.

========= 휴식 =================


지금까지 다룬 내용은, 디자인은 중요한 주제다. 현재 더 중요해진다.
많은 것들이 변하기 때문이다.

반응적 설계의 목적은, 기능들을 계속해서 이어지게 오는 것이다.
이것들은 명확하게 나와야 한다. 디자인의 목적은, 적절한 디자인을 구축하는 것이다.

-----------------------
	Time	Options
Revenue	Sooner	More
Cost	Later	Less
-----------------------

동시에 다 해결할 순 없다.
더 많은 돈을 벌고, 쓰는 것은 적게 해야 한다.
하지만, 시간도 중요하다.

(중간에 잠깐 딴짓하다가 못들었음 ㅠㅠ)

얼마나 많은 옵션을 만드느냐도 중요하다.
옵션을 만들어서, 돈을 덜 쓰도록 해야 한다.
비용 절감을 할 수 있는 방안을 찾아야 한다.
상충/모순 되고 있다.

초기에 많은 돈을 투자하면 옵션이 더 많이 나온다.
4가지를 다 동시에 할 수 없다. 제약요건이 과도하다.

효율성.
사람들이 하고자 하는 디자인에 대한 스타일을 들어보니,
소프트웨어 디자인이 효율적이어야 된다는 것.
효율성은 아주 적은 스케일로 측정할 수도 있고,
큰 스케일로 측정할 수도 있다.

효율성을 큰 스케일로 볼때 효과가 크다.

제조업에서,
기계에는 효율성이 있는데, 전체 공장엔 효율성이 떨어짐.
어떤 경우에, 전체에 효율성이 있으려면, 기계를 덜 돌린다.

소프트웨어 디자인도 그렇다.

Efficiency

Initial work
Cost of features
Cost of changes
Cost of mistakes
Oppotunity cost

* risk

디자인을 어떻게 할까라고 생각할때, 이러한 비용 요소를 모두 고려해야 한다.
변화와 관련된 비용.

가능한 저렴하게.
테스트를 작성하고, 자주 돌리는 이유는,
협업을 하는 이유는,
많은 통합을 하는 것은,
변화를 하더라도, 비용이 많이 들지 않도록 하기 위해서이다.
변화의 비용을 절감하기 위해 노력.

반응적 설계는, 주로 변화 비용을 감소하기 위한 것과 관련 되어있다.

설계 걸정을 할땐, 모든 완벽한 것이 불가능함.
우린 사람이니깐.
실수를 한다.

실수의 비용도 반영을 해야 한다.

초기에 많은 작업을 할 수 있지만, 많은 실수를 하기 때문에,
이런 실수를 고치기 위해서 비용을 반영한다.

Opportunity cost는 경제학에서 온 개념인데,
예를 들어서, 아이스크림을 산다.
그렇기 때문에, 장난감 물총을 못 샀다.
아이스크림 콘은 1달러인데,
물총을 사는 기회가 없어졌다.
이것도 비용이다.

기회 비용은, 프로젝트 초기엔 상당히 클 수 있다.
실질적으로 가치가 있는 것이 무엇인지 알 수 없기 때문.

초기에 많은 작업을 하면,
이와 관련된 기회 비용은 상당히 올라갈 수 있다.

모든 투자를 하나에 옵션에 집어넣는 것이 아니라,
단지 확신을 가졌을 때만 투자를 하도록.

이 모든 요인은 risk가 결부 된다.


예를 들어,
3년에 10억을 벌겠다. 투자를 해달라.
꽤 괜찮은 제안일때.

실질적으로 매출 10억까지 올라갈 확률?
예를 들어서, 그 확률이 0.0000001 이면,
좋은 투자대상이 아니다.

소프트웨어 디자인의 효율성을 평가함에 있어서,
리스크를 고려해서, 실패 리스크를 줄였을 경우에,
이것이 다른 스타일보다 나을 수 있다.

후자가 높더라도.

그래서, 반응적 설계를 보면서, 이러한 변화에 대해서..




이런 비용을 고려하고, 리스크를 고려하고,
리스크를 줄일 방법을 고려하면,
좁게 보면 비쌀 수도 있지만,
전체 시스템 상으로 보면, 비용이 덜 할수도 있다.

사실, 반응적 설계의 목적은,
보다 높은 효율성을 달성하는 것.

현재 소프트웨어에서 지출하는 것보다 덜 쓰는 것.



Latency, Throughput, Variance

예전에, 스웨덴의 한 호텔에, 회전문이었는데,
사람들이 통과하려 하는데,

내(켄트벡)가 생각했다.

"이거 소프트웨어 디자인과 똑같네"

이건 사실 건강한 사고는 아니죠. 여러분들은 그러지 마세요 (ㅋㅋㅋㅋ 개발자 개그)

이 시스템을 어떻게 다르게 설계할까?

이걸 좀 더 효율적으로 만들고자 한다.
여기에 모터를 달아서 빨리 회전.. -_-;;

옆에 문을 두고, 굳이 회전문을 둘 필요가 없다.
온도 차이를 관리하기 쉽지 않다.
회전문의 목적이 그것이다.

어떤 경우는, 문으로 다가가는데 줄이 서있었다.
어떤때는 바로 통과한다.

이 시스템을 보면, 문을 통과하는 사람이 1시간에 얼만가?
시간당 몇명이 통과하는가를 측정할 수도 있다.
그것이 바로 처리량(throughput)이죠.

이 시스템에 대해서 다양한 디자인을 평가하면,
여기 사람들이 문 앞에서의 대기시간(latency)을 평가.

어떤건 throughput엔 좋지만, latency에는 안 좋다.
이 문을 작게 만들 수 있고, 항상 돌아가고 있다.
throughput엔 좋지만, latency는 안 좋다.

여기에 trade-off가 있다.

어떤 경우는 바로 통과, 어떤 경우는 줄이 있다.
이것이 variance

우선적으로 할 수 있는 것이 있다.
문을 더 크게 만들 수 있다.
많은 사람들이 한꺼번에 통과하도록 할 수 있다.
하지만, 회전문이 크면 클수록, 넘어지거나 부딪힐 수 있다.

내가 살고 있는 세계를 확장해서, 시스템을 더 크게 봐야 한다.

헐...

내가 여기 괜찮은 커피샵이 있다.
이 커피샵 때문에, 사람이 많으면..

그러면, 이쪽 안에다가 커피를 팔 수 있는 스탠드를 만들자.
점심시간에 사람들이 몰리면, 점심시간을 나누는 것도 괜찮다.

한걸음 뒤로 나간다. 내가 이 문제에 깊이 관여하고 있을때는 전체를 보지 못한다.

여기서 자꾸 버그가 생기면, 내가 이 기능을 뺄 수 잇는지??
좀 더 나아가서, 근본적인 문제를 해결.

예를 들어,
내가 구현을 하기 이전에 디자인을 먼저 하게 되면,
주로 throughput에 포커스를 맞춘다.
시간을 덜 걸리면서, 시스템을 더 많이 디자인 할 수 있다.
더 빨리 디자인 할 수 있다.
그렇지만, variance 부분이 나빠지고, latency도 나빠진다.

다양한 디자인 스타일에 대해 볼 때에,
내가 현재에 어떤 부분을 보고 있는지 염두해두는 것이 도움이 된다.

모든 상황마다 같은 방식으로 디자인하는 것이 아니다.
고객이 얼마나 될지 모를땐, throughput보다는 latency에 포커스를 맞춘다.

좀 더 정교하게 해야할 경우엔, throughput에 맞춘다.






Challenges

- Human
- Social
- Sensitivity
- Succession (계승. 단계..)
- Uncertaintly


몇달동안 작업했던 클래스들이 어느 한 순간 통합이 된다.
그 순간이 정말 만족스럽다.
그만큼 만족감을 얻는다는 것은, 그만큼 힘들기 때문.

사람이 하는거기 때문에 힘들다.
사람은 반복적인 일을 계속해서 똑같은 방식으로 하는걸 잘 못한다.

사람이 구체적으로 detail하게 하는건 잘 하지 못한다.
detail한 소프트웨어는 힘들다.
그만큼 힘들다.

다른 문제는, 감성적인 부분.
사람이기 때문에.
이게 잘 될껀지, 어떤 효과가 있을껀지, 이게 효과가 없으면 사람들이 날 바보로 생각할껀지.
디자인 관련된 결정을 준비가 되었다 하더라도, 감성적으론 안되었을수도.
디자인은 사회적인 활동이다.

Parser Generator를 사용하면 좋은데,
다른 팀원들이 이해를 못하는 경우엔,
parser generator를 소개하기보단,
하지 않고 재귀하강파서를 사용하는 쪽으로..
상호작용이 필요하다 디자인은.

JUnit에서도 이런 일이 있었다.
rule이라는 걸 추가했는데,
테스트를 파워풀하게 만드는 방법이었는데,

커뮤니티가 이걸 소화하는데 시간이 좀 걸린다는 것을 알게 되었다.

rule을 extension을 하는 것도 좋지만,
커뮤니티도 있고, 소화하는데 시간이 좀 걸리니깐,
rule은 그 다음으로, 4.8에선 손을 대지 않겠다. 그 다음에 손을 대겠다.

(와 소름돋아)

이 전체 컨텍스트, 어떤 작업환경 하에 있는지도 염두에 둬야 한다.

- sensitivity
1년이 지나서, "아. 우리가, 이 작은 변경사항을 1년전에만 했더라도,
우리가 하려던게 훨씬 쉬워졌을 것이다. 하지만, 우리가 하지 않아서 어려워졌다."
..라는 경험이 많이 있을텐데,
나비효과. 나비를 봤더라도, 나비가 날개짓을 할 수 없게 할 수 있냐?;;

- Succession
살고 있는 곳 옆에 고속도로가 있는데, 교량 작업을 하고 있는데,
그 사람들이 교량을 교체시키는데 드는 시간의 반 이상이,
일시적인 임시 방편의 작업을 하고 있다.
예를 들어, 그 중간에 임시로 다리를 구축하고,
잠시만 교통을 다루기 위해서 임시로 구축을 했다.
이것 자체도 값이 많이 들었을 것이라고 생각한다.
하지만, 이걸 놨기 때문에, ..

만일, 내가 처음에 이런 작업 과정을 처음부터 생각했더라면, 이런 식으로 처음부터 디자인하지는 않았을 것이다.
처음부터 고려했더라면.
이 사람은 순서를 생각했을 것이다.

디자인을 어렵게 하는 것이, 불확실성.
소프트웨어가 왜 가치가 있을건지, 얼마나 있는지.
또, 어떤 패턴, 어떤 사람들이 패턴을 사용할껀지.
점진적으로 많이 쓰는지, 어떤 사용방식이 생길지 예측할 수 없다.

또 한가지는, 특정한 기능들에 대해서는 소프트웨어를 어떻게 디자인 할껀지.
이런 고민을 한다.

그렇기 때문에, 똑같은 소프트웨어에 대해 디자인을 다섯번을 하더라도, 각기 다른 방식으로 할 수 밖에 없다.

조그만 디자인을 하나씩해서, 조금씩 변경을.
기술도 바뀐다.

constratint도 바뀐다.


Uncertainties

- Value
- Means
- Technology
- Team



팀도 바뀐다. 멤버도 바뀐다.
알 수 없다. 바뀌는 것이 많기 때문.

(그런 말이 있죠. "절대로 바뀌지 않는 것은, 모든 것이 변한다는 것이다.")




====================================================


기능들이 순차적으로 나오게 하고,
소프트웨어 디자인의 도전이 어느정도인지,
경제적 요소, 개인적 니즈, 사회적 니즈, 기술적 니즈,
이걸 모두 고려하는게 디자이너의 역할

이렇게 어려운 상황 반응하면서
무엇을 배우는지.

제가 특히 반응적 설계에서 배운건,
3가지인데, 이걸 설명하자면, 디자인을 더 잘하게 된다.


====================================================




< 점심시간 >




====================================================



설계에서 가장 중요하게 생각하는게 가치다.

Values

- Feedback
- Humanity
- Courage
- Ambiguity




- Feedback
피드백이 좋아야 한다. 모두 알고 있다면, 디자인에 피드백이 
테스트를 읽거나 쓰는데 문제가 있으면, 좋은 디자인이 아니다.
피드백은 다양한 레벨로 받을 수 있다.
다른 사람으로부터 받을 수도 있고,
프로덕션의 시스템으로 받을 수도 있다.
내 디자인 스타일에선 피드백을 원한다.

- Humanity
두번째 가치는 인간적인 부분.
잘 할 수 있는걸 ?? 해야하고, 못하는걸 피해야 한다.

- Courage
두려움이 있음에도 불구하고, 앞으로 더 나아가는 것.
Don't move forward. 두려움이 있을때.
하지만, 용기는 개선할 수 잇는 것이다.
용기는 개인이 개발(개선)할 수 있는 것이다.
좀 쉬고, 앞으로 가자 할 수 있다.

- Ambiguity
모호성. 여러분의 디자인은 모든 과정에 걸쳐서 다 좋지는 않을꺼다.
어떤 부분은 괜찮고, 어떤 부분은 안좋다.
시작은 좋지만, 어느 시점에 이르게 되면, ugly하게 된다.
왜냐면, 과거에 해결하지 못한 문제를 해결하게 된다.
반응적인 디자인으로서 그러한 모호성의 순간에 가치를 둬야 한다.


바둑에서, 초보랑 고수랑 다르다.
그 차이점을 보면, 초보는 모호성을 굉장히 싫어한다.
그래서 초보자는 한 칸을 보면서, 다음수는 어떻게 될까 하고 고민한다.
아는 방식으로 한다.
하지만, 고수는 모호성을 인정한다.
물론, 결과는 모르지만,
이쪽으로 하지. 안되네? 저쪽으로 하지.
복잡해진다. 기회도 많아진다.
소프트웨어 개발도 그렇다.

굉장히 간단한 규칙을 하는 사람이 있다.
두번 이상 반복되면, 컴포넌트로 만들어야 한다.

하지만, 모르는 경우도 있다.
모호성의 순간을 인정한다는 것.

이쪽 부분은 좀 추해지고 있는데, 어떻게 해야할지 모르겠다.
아무것도 안해야겠다 라고 할 수 있다.
하지만, 초보는 내가 정리를 하겠다라고 한다.
하지만, 문제는,
그 디자인을 깨끗하게 하기 위해서 선택한 디자인 방법이
오래 갈지 모른다.
하지만, 결국 선택이 잘못되엇으면,
더 많은 노력을 해야한다.
다른 방법을 동원해야 되기 때문.

이렇게, "추해진다"는 상황을 인정하는 것이다.
내일은 더 추해진다.

괜찮다.
때가 되면,
그 순간이 되면,

디자인 아이디어가 보이고,
그렇게 되면,
그것을 해결하기 위한 방법을 동원할 수 있다는 것이다.

이것은 그렇다고 해서, 막 혼란스러운 디자인을 요구하는 것인가?
그렇다.
정리가 안 된 디자인은,
깨끗해보이지만, 깨끗해질 준비가 안 된 디자인보단 낫다.

Copy & Paste를 4번 하고, 뭔가 좀 이상하다가,
다섯번째 C&P를 할때 패턴을 발견할 수 있다.

이게 바로, 그런 상황에서 반응적 설계 전략이다.
그냥 그 상태로 추하게 두십시오.
그런 후에, 솔루션이 보인다.

어떤 경우에는 의도적으로,
복잡성과 혼란을 권고한다.

디자인을 더 나쁘게 만든다.
모호성을 만들어버린 것이다.
하지만 그 혼란 속에서,
내가 봐야할 그 패턴을 볼 수 있다.
예를 들어, 디자인을 다른 방식으로 나눌 수 있다.

그 부분 자체가 잘 안되었기 때문에, 내가 볼 수 없었다. 상황을.

서로 이익을 주는 관계.

디자인을 서로 이익이 되는 발견 요소들이 있고,
이걸 하나의 프로세스로 볼 수 있다.

디자인을 하는것은 서로 이익이 되도록
요소들을 관련짓는 것이다.

시스템은 엘리먼트로 있고, 이 관계는 이익을 만든다.


Design

- Beneficially
- Relating
- Elements



element는 또 element로 되어있고,
그 자체가 또 element의 구성요소다.


다 디자인이다. - 켄트벡 딸. (10살이라는데 개고수인듯 -_-;)



* Coupling
그 의미가 바뀌었음.
결합력. 처음에 보여줬던 책.
디자이너에게 가치있는 개념.

반응적 설계 디자이너 입장에서는,
coupling은 하나의 요소에서의 변경사항이 다른 곳에서도 또 변경이 필요한 것.

끊임없이 feature를 계속해서 바꾸는거
또 다른 다섯가지 엘리먼트를 다 바꿔야 되고,
이게 비용이 높은 디자인 변화
꾸준한 변화를 가져오는 것이 필요하다.

전체 시스템에 있어서 coupling을 좀 줄이자.
coupling을 이렇게 정의를 내렸을 때, 명확한 개념은 아니다.
어느정도까지 커플링이 있느냐는,
그 성질에 따라 달라지기 때문.

이쪽은 하나의 language에서만 가능한.
두개의 엘리먼트들이.
이쪽에서 바꾸면, 저쪽에서도 바꿔야 한다는 것.

이것은 coupling이 된 요소.

만일, 절대로, 절대로, 10년동안 절대로 language를 바꾸지 않으면,
이쪽 엘리먼트에서 저쪽까지 커플링이라 하더라도,
잠재적으론 맞지만,
실질적으론 커플링이 된걸 보지 못한다.

이거의 약점 중 하나가,
잠정적으로 커플링이 되어있다는 것이다.

그래서, 웹사이트가 복잡할수록 숨겨져있는 커플링이 크다.



구글에 사촌이 일하는데,
8193바이트의 설정파일을 바꿨더니,
커플링이 있어서, gmail이 다운됐다;;;

전화 교환기 시스템 디자인에 있어서 첫번째 룰은,
절대적으로 필요로 하는 엘리먼트는 없다는 것.
왜냐면, 모든 다른 요소와 커플링이 되어있기 때문.


* Cohesion

하나의 엘리먼트의 변경이 다른 엘리먼트의 변경도 야기시키는 환경

하나의 오브젝트를 바꾸면, 다른 오브젝트로 바꿔야 한다.
근데, 이거 하나만 바꾸면 되기 때문에,

Cohesion

- The probability that a change in one sub-element will require a change in all others
- Inversely related to coupling


cohesion을 분석하는게 coupling을 분석하는 것보다 쉽다.
서브 엘리먼트가 3개가 있는데, 서로 coupling이다.
하면, cohesion하다는 것이다. (뭔 소리야;;)

다른 것과 coupling될 확률이 적다.

한쪽에서 변경 때문에, 모든 곳에서 변경되는 그런게.. 음...

뉴턴의 중력의 법칙 처럼 마찬가지로,
cohesion은 증가시키고, couping은 감소시켜야 한다.


다양한 방법들이 있다.


//////////////////////////////////////////////////

구체적인 어드바이스

Safe Steps

- Balance
  - Efficiency
  - Risk
  - Feedback
  - Teamwork

항상 조금 더 작은 단계로 변하는 것이 옵션이 될 수 있다.
우연히 다른 시스템에 영향을 끼치지 않도록 한다.

근데 이렇게 하면 오버헤드가 있다. 효율성이 떨어진다.

micro-scale로 만든다. 추가의 엘리먼트를 넣는 것도 아니고,
거의 일주일 정도 ?를 하게 되면, 테스팅을 하고,
하면 원하는 디자인이 된다.

근데 이런 것을 보면서, 딜레마가 있는데,

효율성도 원하고, 안전하기도 원하면.. 흠.
근데 안전한게 더 중요하다.
내가 안전하게 할 수 있는 방법이 있으면,
이게 시스템에 어떤 임팩트가 있는지 알 수 있으면,
이거 고쳐도 다 괜찮고, 할 수가 있으면,

이런 안전한 단계를 좀 더 크게 할 수 있다.
리팩토링을 크게 큰 리팩토링을 이클립스로 할 수 있다. 자동화 되어있으니.

연습을 할 수 있다. 안전한 단계를 점점 더 빨리빨리.

안전성을 가지고 시작을 하고, 그리고나서 효율적으로 시작한다.

효율성 < 안전성

이걸 활용해서 효율성을 만들어낸다.

아주 고통스럽고 비용이 많이 들어가는 시나리오는,
내 디자인에 여러가지 change를 하고 테스팅을 하는 것.
아니면, production을 한 후에 작동이 안된다.


안전한 작은 단계의 step을 가지고.


이게 실질적인 첫번째 어드바이스다.





-_-a

안전한 단계를 알고는 있었지만, 예전엔 이렇게 열정적이진 않았다.

속도가 나지 않으면, 다른 방법을 찾아서라도,
어쨌든, 안전성을 희생하진 않는다.

(안전성 얘기할때 켄트벡 눈빛이 반짝반짝 했음.)





Strategies

디자인이슈가 있을때마다 노트를 했다.
카드에 기록을 했는데, 2주에 90개가 쌓였다.
좀 시간이 흐른 후에,
이 카드를 보면서,
이러한 개별 경험을 통해 패턴을 추상화 할 수 있을까?

그룹핑을 해보니깐, 4개의 그룹으로 나뉘어졌다.

와우. 이 작업을 하기 전에,
디자인이라는 것은, 예술이다.
...라고 생각했다.

예를 들어, 천부적으로 태어나던지, 갖고 있던지.

하지만, 보니깐, 디자이너로서 보면,

(못들었음;;;;;;)

* Can see?
- Leap
- Parallel

* Can't see?
- Stepping Stone
- Simplification


재능이라는 것이 일종의 학습이 가능한 스킬이라는 것이다.
디자이너들은 이걸 적용할 수 있다. 배우면.

구체적으로 전략을 설명해주겠다.


Leap

- If
  - You can imagine what you want
  - You can build it
  - You can install it

Efficiency 높음
Risk       ??


전략이 있다면, 할 수 있으면 좋다.
하지만, 도약 작업을 할 수 있는 곳은,
같이 일하는 프로그래머가 생각하는 숫자보다 적다.

그래서 이런 변화를 하자. 몇가지 변화를 하겠다.
결국 그렇게 하면 효율적.
근데 그게 안된다.
처음으로 다시 돌아간다.

아니면, 다시 그냥 포기하고 앞으로 나간다.
근데 비용이 많이 든다.

Leap은 한번에 갈아치우는 것.


두번째 전략.
Parallel
내가 원하는 것이 뭔지 알고 있다.
새로운 디자인을 구축하고, 옛날 디자인과 동시에 돌린다.
변화의 리스크가 줄어든다.

수정하기 쉬운 시스템을 원한다.

If
 - you can imagein what you want but
 - you can't build it or install it safely

- support two designs simultaneously

- gradual migration
- forwarding both ways

safety 높음
scaffolding 낮음


새로운 시스템을 조금씩 만든다.
과거의 인풋을 새 시스템에도 보낸다.
그리고, 아웃풋을 새 시스템과 옛날 시스템에서 비교를 한다.

동일한 아웃풋이 나오면, 과거의 시스템을 꺼버리고,
새 시스템을 이용하낟.

시스템을 대체하는 곳에서 적용한다.

비용은..
동시에 두 데이터를 보낼 방법
동시에 두 오퍼레이션
아웃풋을 비교하는 방법도 알아야 한다.
이것이 다 비용에 관련되어잇는데,
하지만 이것은 다 보험이다.

이것이 바로 패러럴 전략이다.



Stepping Stone
- you can't imagine exactly what you want to build but
- you can imagine what would make the end easier/safer to reach

높음 some well-known components
낮음 risk of over-engineering
낮음 lack of feedback

가능한 기능도 있지만, 사실, 정확하게 뭐가 들어가는진 모르겠지만,

리스크는 너무나 과도하게, (못들었음;;;;;)

디자이너 입장에서는 쉽게, 여기에 들어가는 모든 것을 구상해서 집어넣을 수 있다.

이 과정에서 다른 도전과제는 피드백이 없다는 것이다.

6개월,9개월에 걸쳐 프레임웍을 만든다.
그러고나서, 우리의 전제가 맞지 않았구나.
뱅킹 어플리케이션을 이 프레임웍에 돌리기 쉽지 않구나.
오버 엔지니어링을 했구나 하게 된다.
그래서, 필요할대마다 만든다. 프레임웍을.
feature를 승인을 하고,
구현을 하고,
빨리 feedback을 받는다.




Simplification
- If
 - you can't imagine exactly wat you want to build
 - getting to the end is too expensive
- eliminate requirements until you reach a safe step
- Gradually re-introduce requirements

높음 almost always possible
높음 establishes initiative
낮음 non-linearities in cost depending on requirements ordering

이 feature에 대한 제약을 업애버린다.
복잡한 문제에 대해 핵심만 뽑아낸다.

1 * 1, 2*2, 4*4 ...

점점 확대해나간다.
하지만, 이 전략의 단점은, 위험요소는,
requirement 리스트가 굉장히 긴데, 잠정적으로 삭제를 했다.
하지만, 이러한 요구사항을 어떻게 선택하느냐에 따라
개발비용이 달라진다.
만약, concurency가 들어있느넫,
시스템을 먼저 만들고, 그 후에 concurrency를 그 후에 하면 비용이 많이 들어간다.



내가 requirement라고 생각하는데도, 실제로는 요구사항이 아닐수도 있다.
만약, RDBMS가 필요하다고 했는데,
만약, 그게 쫌 이따 하자. 지금은 아무것도 저장하지 안흔ㄴ다 할 수 있따.
처음엔 db가 업을수도, storage가 업을수도 있다.

심플하니깐 파일에 넣을수도 있다.

다음날이라도 10년뒤라도 될 수 있지만, RDBMS가 필요할 수도 있다.




그래서, 이렇게 4가지 전략이 있다.


한가지 강조하자면,

... and One More

- If
  - you can't see how to make adding the feature straightforward
- Add it anyway
- expect to pay the price later

스무스하게, 깨끗하게 시스템에 기능을 추가하지 못할 경우.
추가하세요.
또는 추가 안하고 버려도 되고요.

아니면 그냥, 조건부로 기능을 추가할 수도 있다.
물론, 댓가는 치뤄야 한다. 언젠가는.
하지만, 그럴 가치가 있을수도 있다.

어떤 change가 한 전략중 하나에서 선택할 수 있으면,
저렴하게 변화를 도입할 수 있다.

전략중에 있으면 쓰세요.
근데 여기 없으면, 그냥.. -_-;
(시추 기계 사진이 있음.)
힘으로 해버리는거죠.



첫번째는 안전하게,
그리고 효율적으로.

두번째는 디자인 변화에 있어서 4가지 전략들.
안전하고 효과적인.





(휴식 15분)





< Refactoring >

- Bi-directional
- Isolate change
- Interface or implementation


예제를 좀 더 준비를 해왔으면 좋았을텐데, 아쉽다.
이 4가지 경우가 아니면, 어떤 방식으로 했는지 생각을 해주시길 바란다.

디자인 변경이 있었을때, 이 4가지 중에 어떤 것에 있었는지..

그래서, 지금부터 여러분이 하실 exercise는 이런 strategy에 대해 생각하면서,
매일매일 작업과 어떤 식으로 관계가 있는지 생각해보길.


///////////////////////////////////////////

일반적인 리팩토링은 A에서 B로 가는데,

한번에 가진 않고, 단계별로 가는데,

Leap은 한번에 와장창 가는거고,

그것도 리팩토링에 적용할 수 있다. 자신만 있다면.

새 기능을 추가할 때에,

디자인을 바꾸는 것과, 기능을 추가하는 것을

동시에 하지 않는 것이 좋다.

리팩토링은 새로운 기능을 추가할땐 쓰진 않는다.

이 4가지 방법은, 기능을 추가하는 과정에도 쓸 수 있다.

///////////////////////////////////////////




< Refactoring >

- Bi-directional
- Isolate change
- Interface or implementation



리팩토링을 master한다는 것 자체가 반응적 디자인에서 중요한 것이다.
리팩토링 책에는 편견이 있다.
프로그램의 구조를 바꾸는 것인데, 결론에 대해선 임팩트가 없는 것이다.
심플한 리팩토링은, 일부를 빼서, extracting을 해서 이걸 쓰는 것인데,
원래의 메소드가 크거나 복잡하지 않다.


리팩토링을 하더라도, 똑같은 테스트도 똑같이 된다.
이것이 중요한 특성인데,
responsive design의 다른 부분은,
structure나 behavior를 동시에 변경을 해서는 안된다.
리팩토링만 하는 모자가 있고,
새로운 기능을 추가하는 모자가 있는데,
두 모자를 한번에 쓰면 안된다.

여기에 +1 을 하면, 해답이 바뀐다.
그래서, 우선은 구조부터 바꾸고 나서,
테스팅을 먼저 하고,
테스팅에서 fail이 되면, +1 을 해서 또 테스트를 한다.

이게 responsive designer가 하는 방법이다.

구조와 동작을 동시에 바꾸지 않는다.

근데, 원래의 리팩토링 책은 좀 다르다.
예를 들어, extracting method이 구체적으로 나와있는데,
그 역으로, inline 리팩터링인데 이것 역시 extracting method만큼이나 유용하다.

메소드가 있는데, 굉장히 짧고, 심플하고,
이름을 붙일 필요가 없으면, inline 뭐시기로 한다.
테스트케이스에서도 똑같은 해답이 나온다.

리팩터링은 어떤 방향으로라도 할 수 있어야 한다.
즉, 양방향(bi-directional)이어야 한다.


interface나 implementation을 바꾸지만,
동시에 바꾸지는 않는다.

interface를 바꾸고, 테스트를 다 하고, 다 되는지 보고,
그것이 괜찮다면 implentation을 한다.
두가지 단계로 한다. 동시에 안 하고.


Isolate change
- Before making a change, reduce risk by isolating the area that will need to be changed.


이러한 테크닉은 월요일 아침에라도 활용할 수 있는 테크닉이다.

첫번째 예.
method의 일부를 변경하고자 하면,
몇개의 라인이 있고, 두개 라인을 변하.
이렇게 고립 변화 전략에 따르면, 이 라인을 편집하기 이전에,
이것으로 element를 만든다.
extract method를 적용해서, ..
한 후에, 이 두 라인을 편집한다.

(안전을 위해서, 고칠 부분을 먼저 뽑아낸 후에 한다는 이야기인듯?)

코드의 어떤 부분의 영향을 미치는지 정확히 안다.

coupling과 cohesion에 대한 정의를 다시 보면,
여기 두 라인이 element다.

그 후에, 다시 inline시키더라도,
responsive design에 따라서 하는 것이다.

또 다른 사례로는, internalization이다.



굉장히 많은 노력을 해서, 굉장히 쉽게 되도록 한다.
노력을 한 다음에, 변경으?


(못들었음;;)


많은 노력을 해서, 원하는 변경이 쉽게 되도록 하는.

Thread-safe가 어렵다.


JUnit에 대한 내용...(....)



플랫폼이 나와서 새로운 기능을 낼 수 있게 되었다.
굉장히 짧은 시간 안에, 큰 가치를 할 수 있었다.



Design is an island

- No "best" design
- Improvement
- Deterioration
- Sea level
- Change in basis



------------------------


Power Laws

dependencies..
평균치라는 것은 시스템 자체의 complex와 관련되어 알 수 없다.
(이상한 그래프 그림 있음;; 그래프는 메모장으로 필기를 할 수가 없잖아?!)

매트릭스를 가지고 작업한다면,
평균치의 의미에 대해 조심스럽게 접근해야 된다.

주의할 점은,
아무도 이런 패키지를 디자인하려고 하진 않았을 것이다.
디펜던시가 40개나 되는.. -_-;
여러가지 잘못될 수 있는 것들이 많이 있다.
이성적인 디자이너라면 처음부터 이렇게 만들진 않았을 것이다.
하지만, 진행하다보면, 이렇게 되게 된다.
우리가 디자이너로서 합리적인 판단을 내리지 못하고 있다는 것으로 받아들여진다.

내가 시스템을 컨트롤 하고 있다는 환상은 가지고 있겠지만,
이 소프트웨어 디자인의 한 측면이,
자연의 산물이기 때문에,
소프트웨어를 만들기 위해서,
"우리를" 활용하고 있는 것이다.

굉장히 강력한 힘가 우리에게 영향을 주는 측면에서,
우리가 작업하고 있는 거이다.

시스템은 굉장히 복잡하지만,
우리는 그것을 인정해야 된다.

내 시스템의 복잡성은 내가 컨트롤 할 수 있다고 생각하는 것 보다는,
이 현실을 인정하는 것이 옳다. 그것이 더 건강한 태도다.

내가 책임을 지지만,
외부의 그러한 영향력이 있다.
힘이 있다는 것을
인정해야 한다.

이러한 두가지 생각을, 내가 어떻게 밸런스를 유지하느냐 하는 것도 중요하다.

어떤 프로세스라도,
이런 형식의 power laws가 나오는 경우가 많다.

복잡한 method가 있는데, 또 새로운 feature가 있다. 하면,
그 method가 더 복잡해지도록 만드는 경우가 훨씬 더 많다.

부익부 현상이라고 할 수 있다.

그 프로세스를 인식을 하고, 제일 밖에 있는 이런 outline을 가지고
이걸 분리해야할 때가 생긴다.
이 기울기를 바꾸려는 노력에 대한 인식이 있어야 한다.

이것이 책임성이 있는 responsive designer의 역할이다.





Fractal

이런 현상들을 관찰은 했지만, 설명은 잘 할 수 없는 부분들.
element 안에 element 안에 있는 element한 것들이 fractal한 구조들.





Symmetry

symmetry를 이용해서 element를 함께 모이게 한다.
또는 분리하던가.
찾고자 하는 symmetry는 field를 찾고, 동일한 라이프타임을 갖는 걸 찾는다.
누군가가 항상 여기에 다른 field를 집어넣는다. -_-;; (나쁜놈이네)
나머지 field의 symmetry를 깨지게 하면, 이 field는 딴데 넣어야 한다.

똑같은 수준의 exception을 가진 3개의 expression이 있는데,
하나는 다른 manipulication이 있다.
그래서 나머지 두개완 다르다.
방법을 찾아내서, symmetry를 회복하고자 한다.





Punctuated Equilibrium

다윈이 진화론을 설명할때, 그에 따르면,
진화는 점진적으로 일어나낟.
하나의 모양에서 다른 모양으로 갈땐, 점진적으로 가고,
시간적으로 균등하게 일어난다고 한다.

근데, 화석 기록??을 보면,
very rapid rates of change하는 부분이 있다.
어느정도까지는 동일하다가, 갑자기 변하는 타이밍이 있다.

제가 생각하기에, 저희가,
responsive design을 볼때, (못들었다;;;)

소프트웨어도 이런식으로,
조금씩 바뀌다가, 갑자기 급격히 바뀌고 뭐 그런다.

소프트웨어 디자인의 뿌리깊은 곳에서,
이런 현상이 있는데, 이건 뭐라 설명하기 어렵다.
이것이 우리가 디자인하는 방법에 큰 영향을 미친다.
우리가 이것을 이해하면, 훨씬 더 잘하고, 효율적으로 하고,
훨씬 짧은 기간에 많은 기능을 딜리버 할 수 있을 것이다.



Observations

- Power Laws
- Fractal
- Symmetry
- Punctuated equilibrium



/////////////////////////////////////

다음주 워크샵 들으라고 광고 하고 있음 ㅋㅋ

/////////////////////////////////////







Q & A




Q. xp를 팀에 적용하는 것이,
팀의 문화를 바꾸는 것으로 생각한다.
근데 현실적으로 어려움이 있다.
어떻게 당신의 조직을 바꿀 수 있는지,
정석으로는 10년이 걸릴 수 있다고 커멘트 해주셨는데..

A. humanity에 가치를 둔다고 했는데,
변화를 하는데 상당한 오랜 시간이 걸리는 것을
인정하는 것도 중요하다.
새로운 소프트웨어 개발에 대한 워크샵을 하고 인증서를 줘서,
하루아침에 바뀌면 좋겠지만 그렇지 않다.
DNA를 다운로드 받을 수 있으면 좋겠지만, 그렇진 않다.
반면에, 변화는 일어난다.
어떤 경우는 빨리 진행되는 경우도 있다.
변화도 단계적인 평형 과정이라 생각한다.
개인이나 팀이 적절한 상황에서, 빠르게 변하기도 한다.
하지만 유감스럽게도, 적절한 조건은 별로 없다.

만약, 팀이 해고될 조건이다;;;
그럼 빨리 바뀐다. -_-;;;;; (사람들 웃음)
초기에 xp를 밀어붙였다.
그래서 다른 사람들한테, 해봐라. 진짜 해봐라. 날 믿어라. 그렇게 얘길 했다.
하지만, 아닙니다. 사실, 사람들에게 밀어붙이면 안 좋아한다.
그래서, 신시아와 함께 다른 방식을 했다.

Appreciative Inquiry라는 방법인데, 다음주 강연 내용이다 ㅋㅋㅋㅋㅋㅋㅋㅋ
(180만원짜리 워크샵 소개 -_-;; (사람들 웃음))

그래도 간단히 말하면,
누군가에게 pair programming을 해라. 이런것 보다는,
어떤 사례나 경험을 얘기해주거나,
서로의 문장까지 끝내줄 정도가 되었다.
누가 어떤 코드를 썼는지 모를 정도가 되었다.
얼마나 일을 했는지, 어느정도 쉬었는지,
어떤 느낌을 가졌는지..

그런 다음에 이렇게 마무리를 했죠.
다 좋게 들리네요.
다 그런 마술적인 느낌을 받으려면 어떻게 해야 되나요?
..하고 질문을 한다.

그래서, 여기서 흥미로운 것은,
아무것도 밀어붙이지 않는다. 홍보하지 않느낟.
굉장히 관대한 프로세스이다.
누군가에게 격려를 해서, 긍정적으로 기억하게 한다.

좋은 기술적인 협업을 격려할 수 있게 되면,
화이트보드가 필ㅇ하다, 코드리뷰가 필요하다 라고 하겠죠.

이것에 대해 컨트롤할 수 있는지는 모르겠지만,
변화를 격려할 수 있는 중요한 요소다.
긍정적인 감정이, 지식만큼이나 변화에 중요하다.
이러한 두가지를 결합시키면,
방법을 주고, 방향을 설정해주고, 하면 좋다.

이것이, 문화/변화를 유도하는 방법이다.


(여기서 김창준님 등장해서 코멘트)
이걸 AI라고 하는데, 번역서가 나왔다.
Appreciative Inquiry
한번 읽어보시길. (관련글 : http://agile.egloos.com/5104406 )



Q. 가정적인 사람이 되기위한 비결이 있냐?
A. 가족은 평생 가는거잖아요?
가족에게 투자를 해야한다. 시간과...
근데 그걸 어떻게 하느냐?
어떤때는 성공을 하고, 어떤때는 실패를 한다.
정확한 답변을 드릴 수 없다. (웃음)

(몰랐는데, 켄트벡이 좀 가정적인가보다?)



Q. (질문을 못 들었음)
A. 한국 개발자들과 요 몇일동안 질답을 하다보니,
사람들이 강력하게 책임감이란걸 느낄 수 있다는걸 알아차릴 수 있었다.
근데, 그 책임감이 너무 과도하게 하면, 너무 적은것보다 나쁘지 않을 수 잇겟지만,
그만큼 더 나쁠 수 있다. 너무 과도하면. 효율성 측면에서.
두개의 팀이 있었는데, 켄트벡 친구중에 한 팀이 있었는데,
매니저가 와서, 이쪽에는 이 사람들이 그만큼 더 시간을 많이 들이는데,
시간이 모자라지 않느냐?
근데, 저 사람들처럼 주말에도 나오고, 밤에도 나와야 되지 않겠냐? 했더니,
제 친구가 답변했다.
도움이 될꺼 같으면, 나도 할꺼다. 만일 그렇게 해서, 우리가 너무 지칠대까지 일을 해서
그게 효과가 있으면 하겠지만, 효과가 없을 것이다.
매일 아침마다, 우리가 휴식을 취한 상태로 일을 하러 와야 한다고 생각한다.
내 프로젝트에 내가 전적으로 집중할 수 있도록 휴식을 하고 와야 한다.

켄트벡 왈, 뇌가 컨트롤 할 수 없는 상황에는 일이 안되기 때문에,
뇌가 가장 효율적인 상태로 소프트웨어 개발을 할 수 있는 방법을 생각하라.
너무 무리해서 하면, 건강이 나빠져서 일을 하나도 할 수 없는 상황이 될 수 있기 때문에,
뇌가 어떤 상황에서 가장 적절하게 할 수 있는 어쩌구..
휴식을 취하라.

문화적으로는 아마도 어렵겠죠. 만일 주변에 있는 분들이
시간만 본다면, 아마, 에너지 레벨을 그만큼 중요시하기 쉽지 않ㅇㄹ 것이다.

객관적인 시간을 가지고 보는 것은 어렵지 않다.
근데 거기에 대비해서, 어제 얼마나 휴식을 취했고,
오늘 아침에 얼마나 전념할 수 있는 상태로 왔는지
이런 상태를 보는 것이, 우리 팀에게 고객에게 얼마나
만족을 줄 수 있는지 하는 것을 염두에 둬야 한다.



Q. 한달 수입이 얼마나 되나요?
A. 상관 없잖아요? 여러분하고. (사람들 웃음. 좀 궁금했는데..)



Q. 리팩토링 수련하고 있는데, 딜레마에 빠져있다.
검증을 해야되는데, 대부분의 디자인이 인터페이스를 바꿔야 하는 상황이 많다.
왜냐면, 초기 디자인이 인터페이스를 견고하게 디자인하지 못했기 때문인데,
어떻게 이 상황을 극복할 수 있는지. 테스트를 통해 검증하고 싶은데,
인터페이스를 바꾸기 때문에 테스트가 계속 깨진다.

A. 흔하게 발생할 수 있는 일이죠.
제가 첫번째 따르는 규칙은, 인터페이스나 임플리멘테이션은 항상 바뀌지만,
동시에 바꾸지 말라는 것이다.
인터페이스를 리팩토링 하게 되면, 테스트는 여전히 잘 되야 된다.
예를 들어서, 인터페이스를 바꿔서, 테스트가 break되는 순간이 있다.
그 순간을 가능하면 짧게 하고자 한다.
그래서, implementation에 무엇을 해야만이,
내가 인터페이스를 가능하면 빨리 바꿀 수 있도록 하는가?
그리고 또 가능하면, 테스트를 가능하면 빨리 fix할 수 있을까?
답이 오히려 더 질문 같네요. (웃음)

(만족하지 못한듯. 다시 질문을 한번 더함)

다른 아이디어를 드리겠습니다.
leaf 대신에 패러럴을 적용한다.
인터페이스를 둘 다 유지해서, 테스트를 하고,
old에서 new로 바꾼다.
그 작업이 끝나면, old interface를 지운다.
하지만, 테스트는 그동안 완벽히 돌아갔던 것이다.

인터페이스 변화를 보시고, 이 인터페이스로 저 인터페이스로
한 단계로 갈 수 있을까 고민할 수 있다.
하지만 그렇지 못할 수도 있으니,
이걸 나뉘어야 할 수도 있다.
simplification을 적용해서,
여기까지 갈 수 있으면, 저기까지도 갈 수 있을꺼라고 한다.
인터페이스에 대해 다음 change를 할 수 있도록.
궁극적으로는, 마지막 interface까지 갈 수 있다.



Q. 사려깊게 생각하고 디자인을 했다가, 변경하다가, 생각치 못한 요소가 있는데,
성격상 조급해서 그런 부분이 있는 것 같은데,
아기걸음이라던가 그런 방법으로 성장시켜나가야 하는건지,
아니면, 그런 부분을 잘 커버할 수 있는 practices가 있는지?

A. 알아들은대로 답변을 드리겠습니다.
디자인 스킬을 어떻게, 획득을 하느냐에 대한 질문을 하는 것 같은데 맞나요?

Q: 그렇다기보단, 항상 빠뜨리는 부분이 있는데, 자기가 납득할 수 있는 수준보다 더 많이 빠뜨리고 있다.
조급함 때문인 것도 있는 것 같지만, 이것에 대한 어떤 해결책이 없는지?

A: 예. 아주 어려운 질문이네요.
한가지 구체적으로 말씀드릴 수 있는 것은요. 숨쉬기. (사람들 웃음)
우리 아이들이 아마 하루에도 수십번씩 한다는 것을 알수 있을 것이다.

그리고, 두번째 하신 말씀,
그래서 이걸 제가 좋은 방식으로 얘기할 수 있을지 생각하고 있는데, 그냥 말씀드릴께요.
조급함이라는 것은 젊은이들이 가지고 있는 질병입니다.
그런데, 이것을 고치려면, 부작용도 심합니다. (헐;;;;)
조급하다. 만일 내가 조급하다고 하면,
일단은 인정하는게 좋겠죠.
그런데 내가, 이걸 긍정적으로 본다면,
내가 이 팀에 에너지를 가지고 기여를 할 수 있다.
그러니깐, 내가 지금 막 한 것을 이렇게 하지 말았어야 하는데,
하지 말았어야 하는걸 보여줄 수 있다?;

나이 들면 점차 안정성을 팀에게 주겠죠.
근데, 그때도 또 인정해야 하는것이,
사람마다 각기 팀에 기여하는 것이 다르다는 점이다.
그리고 또 어떤 사람은,
내가 일하는 방식이 아니지만..이라고 얘기하는 사람도 있을 수 있다.
근데 아마, 젊은 사람들이 실수를 할 때에, 청소해주고 마무리 해주는 해결사 역할을 하시겠죠.

어떤 사람이,
내가 이런 실수를 할 수 있게 해줘서 감사하다고 했다.
어떤 경우는,
제가 실수를 하는 경우도 있다.
그럴때도 역시, 제가 오래 해왔지만,
그럼에도 불구하고 실수를 해왔다는거, 배울 수 있다는거,
반갑게 생각한다.

팀 내에서 에너지 레벨을 올린다는 것도 좋을 것 같다.
하지만, 점진적으로 바뀌겠죠.

팀 내에서 각기 다른 역할을 가지고 있는 사람이,
매일매일 최선을 다해서..

30~40년 하고 은퇴할때까지 ㅎㅎ



Insights

어떤 사람 : 문제를 한걸음 뒤에서 해결해야 한다는 것에 감동을 받았다.
다른 사람 : 제약조건을 고려하여, 해당 방법대로 하려면, 높은 수준의 디자인 능력이 필요할 것 같다.




마지막에, 켄트 벡이,

디자인은 절대로 쉽지 않다고 언급했다.



세미나 끝.

///////////////////////////////////////////////
///////////////////////////////////////////////
///////////////////////////////////////////////
///////////////////////////////////////////////
///////////////////////////////////////////////



종텐이 필기한 내용은 여기까지입니다.
시간이 없어서 다듬지 못했습니다. (파스칼 패러디)
기록했던 그 순간 그대로 배포합니다.
라이센스는 "대인배 라이센스"입니다. 마음대로 하세요.

녹음 하셨다는 분도 있는 것 같던데,
그 자료와 같이 보시면 도움이 될지도 모르겠습니다.

몇몇 insight를 받긴 했지만,
내공이 짧아, 영속성이 부여되는 글을 이용해 뭐라 평하기 어렵네요.
추가적인 의견은 이 글에 기록하진 않겠습니다.

삶의 밸런스를 유지하는, 행복한 개발자가 되시길 바랍니다.


-- 이상한 나라의 종텐 / www.jong10.com