우연히 1년 전에 쓴 소프트웨어공학 TOP 75 도서 관련 포스트를 다시 보게 되었다.

75권의 책 중 몇 권이나 읽었냐는 댓글에 내가 8권밖에 읽지 못했다는 답변을 단 것을 다시 보니,

1년이 지난 지금은 상황이 어떻게 변했을까 스스로 궁금해져

한번 follow-up 을 해보았다.

펼침/접힘 단어 입력 : <소프트웨어공학 TOP 75 도서> 원글 정보

Top 100 Best Software Engineering Books, Ever

from: http://www.noop.nl/2008/06/top-100-best-software-engineering-books-ever.html

via: http://younghoe.info/925

읽은 책

1 Steve McConnell
Code Complete: A Practical Handbook of Software Construction

3 Steve McConnell
Rapid Development

4 Erich Gamma
Design Patterns: Elements of Reusable Object-Oriented Software

7 Joel Spolsky
Joel on Software

10 Martin Fowler
Refactoring: Improving the Design of Existing Code

19 Andrew Hunt, David Thomas
The Pragmatic Programmer: From Journeyman to Master

25 Tom DeMarco
The Deadline: A Novel About Project Management

28 Thomas H. Cormen, etc.
Introduction to Algorithms, Second Edition

30 Martin Fowler
UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)

36 Jon Bentley
Programming Pearls (2nd Edition)

47 Steve McConnell
Software Project Survival Guide

59 Kent Beck
Test Driven Development: By Example

70 Ron Jeffries, etc.
Extreme Programming Installed

읽고 싶은 책

2 Elisabeth Freeman, etc.
Head First Design Patterns

8 Tom DeMarco, Timothy Lister
Peopleware: Productive Projects and Teams (2nd Edition)

9 Frederick P. Brooks
The Mythical Man-Month, Anniversary Edition (2nd Edition)

16 Donald E. Knuth
The Art of Computer Programming, The, Volumes 1-3 Boxed Set (2nd Edition)

17 Martin Fowler
Patterns of Enterprise Application Architecture

21 Craig Larman
Applying UML and Patterns (3rd Edition)

42 Mary Poppendieck, Tom Poppendieck
Lean Software Development: An Agile Toolkit

45 Joshua Kerievsky
Refactoring to Patterns

67 Johanna Rothman
Manage It!: Your Guide to Modern, Pragmatic Project Management

75 Edward Yourdon
Death March (2nd Edition)

1년 동안 본 책이 5권 정도밖에 안 되는 것 같다.

지금도 보고 싶은 책이 아직 10권이나 남아 있고

앞으로 1년이 더 지나면 또 보고 싶은 책은 더 늘어나 있을 것 같은데...

요즘은 뉴스에 잡지에 RSS에 트위터에...

책 말고도 볼 게 너무 많다보니 책이 더 잘 안 읽히는 것 같다.

쩝, 언제 다 보냐...

( 괜히 했어, 그냥 집에 있을 걸. follow-up 괜히 했어~ )

[번역] 디자인 패턴, 그로부터 15년 후: GoF와의 인터뷰 (1) 에서 계속 이어집니다.

Design Patterns 15 Years Later: An Interview

with Erich Gamma, Richard Helm, and Ralph Johnson

원글: http://www.informit.com/articles/article.aspx?p=1404056&rll=1

Larry:
After the pattern bandwagon, there was a trend towards "anti-patterns."

Are anti-patterns as valuable as patterns?

패턴 열풍 이후에는 "안티 패턴" 이라는 트렌드가 있었습니다.

패턴만큼 "안티 패턴"도 가치가 있을까요?

Richard:
Probably? they provide a way to share and learn from mistakes

아마도요? 실수를 공유하고 실수로부터 배우는 방법을 제공하긴 하잖아요.

Ralph:
I prefer the notion of "code smells," or "design smells"/"architecture smells" etc.

They aren't always mistakes.

Sometimes they are just problems you have to live with.

For example, "stove pipe" systems grew up
partly because companies didn't have good ways of interconnecting their systems,
partly because technology was changing rapidly,
and partly because the different parts of a company didn't cooperate.

In a mature, slowly growing company, stove pipe systems are an architecture smell
that should probably be eliminated using SOA and a strong architecture team.

But in a company that is growing rapidly by buying other companies,
stove pipes are due to the fact that it takes time to integrate a new company.

No amount of architectural leadership will eliminate the problem.

Some of my students wrote a pattern for "Big Ball of Mud."

For most people who read patterns, this is an anti-pattern to be avoided at all costs.

But to a lot of IT organizations, especially ones I've seen in government,
there just isn't enough expertise to do better.

Anything they build will, in a few years,
lose its structure and become connected with everything else.

저는 "코드의 나쁜 냄새" 나 "설계의 나쁜 냄새", "아키텍쳐의 나쁜 냄새" 같은 개념을
더 좋아합니다.

이런 것들이 항상 실수를 뜻하는 것은 아닙니다.

이런 것들은 때로는 같이 안고 가야 할 단순한 문제일 경우가 있습니다.

예를 들면, "스토브 파이브" 시스템이 생겨나는 이유는
회사가 시스템들을 상호연결하는 좋은 방법을 갖고 있지 못하기 때문이기도 하고,
또는 기술이 너무 빨리 변화하기 때문이기도 하며,
또는 회사의 다른 부분들이 잘 협업되지 못하기 때문이기도 합니다.

성숙되고 느리게 성장하는 회사에서는,
스토브 파이프 시스템은 아키텍처의 나쁜 냄새이므로
아마 SOA나 강력한 아키텍처 팀을 통해 제거되어야만 할 겁니다.

그러나, 다른 회사를 합병하거나 해서 빠르게 성장하는 회사에서는
스토브 파이프 시스템은 새로운 회사를 통합하는데 시간이 걸린다는 사실 때문일 겁니다.

아키텍처적인 리더십이 풍부하다고해서 항상 문제가 해결되는 것은 아닐 겁니다.

제 학생들 중 일부는 "Big Ball of Mud" 패턴에 대한 글을 썼습니다.

패턴에 대해 읽은 대부분의 사람들에게
이것은 어떻게해서든 피해야할 안티 패턴 중 하나일 겁니다.

그러나 많은 IT 기관들, 특히 제가 본 정부 기관들에서는
그것은 단지 상황을 개선할 전문적인 기술이 없다는 것을 의미할 뿐입니다.

앞으로 몇 년 동안, 그들이 무엇을 만들던 그것은 점점 구조가 틀어지게 될 것이고,
다른 것들과 서로 엉켜버리게 될 것입니다.

Erich:
Using a code smell or anti-pattern to motivate the use of a design pattern is valuable.

It is difficult to appreciate the value of a design pattern
without seeing the code before and after the use of a design pattern.

디자인 패턴을 사용하는데 동기 부여를 하기 위해
코드의 나쁜 냄새나 안티 패턴을 사용하는 것은 유익합니다.

디자인 패턴을 사용하기 전의 코드와 사용한 후의 코드를 다 보지 않고서는
디자인 패턴의 가치에 고마움을 느끼기가 어렵습니다.

Larry:
GoF came out relatively early in the ascent of OOP as the mainstream paradigm
and, for better or worse, "patterns" seem to be associated with OO approaches.

You even hear functional and dynamic advocates boasting
that their languages "don't need" patterns.

How do you respond to that?

OOP가 주류 패러다임으로 급성장하는 과정에서 GoF는 비교적 이른 시기에 두각을 나타냈는데요.
그리고, 좋든 나쁘든, "패턴"은 객체지향적 접근과 긴밀하게 연관되어 있는 것처럼 보입니다.

심지어 함수적 언어나 동적 언어 지지자들은
그들의 언어에는 패턴이 "필요없다" 라고까지 홍보를 하는데,
이에 대해서는 어떻게 답변을 주시겠습니까?

Erich:
Just as an aside, it is also easy to forget
that we wrote design patterns before there was Java or C#.

그냥 여담으로 얘기하자면,
Java나 C#이 있기 전에는 우리가 디자인 패턴 책을 썼다는 사실도 잊어버리기 쉽상이었죠.

Ralph:
Some of those languages don't need some of the patterns in Design Patterns
because their languages provide alternative ways of solving the problems.

Our patterns are for languages between C++ and Smalltalk,
which includes just about everything called "object-oriented,"
but they certainly are not for every programming language.

I don't think anybody actually says that programmers in other languages don't need patterns;
they just have a different set of patterns.

그런 언어들 중 몇몇은 디자인 패턴 책에 있는 어떤 패턴들이 정말 필요가 없습니다.
왜냐하면 그런 언어들은 문제 해결을 위한 다른 대안을 제공하기 때문이지요.

우리가 디자인 패턴 책에 쓴 패턴들은
흔히 "객체지향"이라고 불리는 모든 요소들을 포함하고 있는
C++과 스몰토크와 같은 언어들을 위한 것이긴 합니다만,
우리의 패턴들이 꼭 모든 프로그래밍 언어를 위한 것은 아닙니다.

저는 다른 언어를 사용하는 프로그래머들이 실제로 패턴이 필요없다고 말했다고는 생각지 않습니다.
그들은 그저 다른 부류의 패턴들을 가지고 있는거죠.

Erich:
Design patterns eventually emerge for any language.

Design deja-vu is language neutral.

While these experiences are not always captured as patterns, they do exist.

The design principles for Erlang come to mind.

디자인 패턴은 어떤 언어에서든 결국에는 나타나기 마련입니다.

설계 기시감(design deja-vu) 은 언어 중립적이지요.

이러한 경험들이 항상 패턴으로 포착되는 것은 아니라고 하더라도, 패턴은 확실히 존재합니다.

얼랭을 위한 설계 원칙이 떠오르네요.

Larry:
Where would a person go to learn about patterns for dynamic and functional languages?
Who's making good contributions?


동적 언어나 함수적 언어를 위한 패턴에 대해 공부하려는 사람은 어떻게 해야 할까요?
누가 기여할 수 있을까요?

Ralph:

If by "dynamic" you mean dynamic object-oriented languages like Smalltalk, Ruby or Python,
then our patterns are applicable.

Functional languages require different patterns, but I don't know who is working on them.

만약 "동적"이란 말이 스몰토크나 루비 혹은 파이썬 같은 동적 객체지향 언어를 뜻하는 거라면
우리의 패턴들을 적용할 수 있을 겁니다.

함수적 언어들은 다른 패턴들이 필요한데, 그걸 누가 연구하고 있는지는 저는 잘 모르겠네요.

Larry:
OOP provides a combination of static and dynamic structure,
allowing the design intent to be communicated along a few different axes
(or at least with different diagrams).

With today's emphasis on functional and meta-programming approaches,
there's not as much static structure.

Instead, there's a lot of talk about communicating design intent
by creating APIs in the context of a "domain-specific language" or a "fluid interface."

Do these approaches replace or complement the patterns in DP?

OOP는 몇가지 서로 다른 축(이나 혹은 최소한 서로 다른 다이어그램)을 가지고
설계 의도가 잘 전달될 수 있도록 함으로써
정적 구조와 동적 구조의 결합을 제공합니다.

함수적인 접근방식과 메타 프로그래밍 접근방식에 대해 최근에 그 중요성이 부각되고는 있는데,
여기에는 정적 구조가 그렇게 많지는 않습니다.

대신에, "domain-specific language" 나 "fluid interface" 와 같은 환경하에서 API를 만듦으로써
설계 의도를 전달하는 것에 대한 많은 얘기가 있습니다.

이러한 접근방식이 디자인 패턴 책의 패턴들을 대체하거나 보완할 수 있을까요?

Richard:
Complement.

Rich class libraries structured well using good design
take on features/characteristics of domain-specific languages.

Reading code for a well designed user-interface toolkit
becomes like reading a domain-specific language for GUIs.

The library constructs become the verbs and nouns of the domain-specific language.

For example, if you go back and look at the code in Interviews/Unidraw
(co-written by John Vlissides),
although the language was C++,
the code could easily be understood by someone who knew how to build GUIs.

보완할 수 있습니다.

훌륭한 설계를 사용해서 잘 구성된 풍부한 클래스 라이브러리는
DSL의 속성이나 특징과 유사점을 갖습니다.

잘 설계된 사용자 인터페이스 툴킷의 코드를 읽는 것은 GUI를 위한 DSL을 읽는 것과 비슷하게 됩니다.

라이브러리의 구성은 DSL의 동사와 명사가 됩니다.

예를 들어, 돌아가서 (John Vlissides와 함께 짠) Interviews/Unidraw 코드를 들여다보게 된다면,
언어가 C++이라고 할지라도,
GUI를 어떻게 만들어야하는지 아는 사람이라면 누구든지 코드를 쉽게 이해할 수 있을 겁니다.

Erich:
While they complement the patterns in DP
it can indeed be the case that meta-programming can replace the design pattern used in a design.

The evolution of JUnit 3 to JUnit 4 comes to mind.

JUnit 3 was a small framework that used several patterns like Composite, Template Method and Command.

JUnit 4 leverages the Annotations meta-programming facilities introduced in J2SE 5.0.

The use of the patterns disappeared
and the framework evolved into a small set of annotations plus a test runner infrastructure
that executes the annotated Java code.

그러한 방식들이 디자인 패턴 책에 있는 패턴들을 보완하는 반면에
메타 프로그래밍이 설계에서 사용된 디자인 패턴을 대체할 수 있는 경우도 실제 있습니다.

JUnit 3에서 JUnit 4로의 개선이 생각나는데요.

JUnit 3는 Composite, Template Method, Command 같은 몇몇 패턴들을 사용한 자그마한 프레임워크였습니다.

JUnit 4는 J2SE 5.0 에서 도입된 Annotation 메타 프로그래밍 기법을 도입해서 개선되었습니다.

패턴의 사용이 사라졌고,
프레임워크는 어노테이션과 어노테이트된 자바 코드를 실행할 수 있는 테스트 실행 인프라가 포함된
작은 집합체로 서서히 발전해갔습니다.

Larry:
Generative patterns: There are 253 patterns in A Pattern Language and 23 in DP.

Do you think the DP catalog fulfills Alexander's edict that
"[A pattern language] not only tells us the rules of arrangement,
but shows us how to construct arrangements - as many as we want - which satisfy the rules"?

생성적 패턴: "A Pattern Language" 책에는 253개의 패턴이 있고,
디자인 패턴 책에는 23개의 패턴이 있습니다.

디자인 패턴 책의 카탈로그가 Alexander의 법칙,

"[패턴 언어]는 배치의 법칙을 알려줄 뿐만 아니라
규칙을 충족하는 - 더 많이 원할수록 더 많은 - 배치를 구축하는 방법도 보여준다"

를 충실히 이행하고 있다고 생각하시나요?

Richard:
No.

It was not the intent to be a prescriptive or generative guide.

The inspiration for me came more from engineering handbooks
where an engineer/designer would reach up to his bookshelf
and find a generic mechanical design for clutches or two stroke engines.

그렇지 않습니다.

디자인 패턴 카탈로그는 규범적이거나 생성적인 가이드를 위해 의도된 것이 아니었습니다.

제 경우에는
엔지니어나 설계자가 자기 책장에 손을 뻗은 다음에
클러치나 2행정 엔진을 위한 일반적인 기계 설계안를 찾기 위해 참조하는
공학 지침서에서 아이디어를 얻었습니다.

Larry:
How would you refactor "Design Patterns"?

"디자인 패턴"을 어떻게 리팩토링하시겠습니까?

Erich:
We did this exercise in 2005.

Here are some notes from our session.

We have found that
the object-oriented design principles and most of the patterns haven't changed since then.

We wanted to change the categorization, add some new members and also drop some of the patterns.

Most of the discussion was about changing the categorization and in particular which patterns to drop.

When discussing which patterns to drop, we found that we still love them all.
(Not really - I'm in favor of dropping Singleton. Its use is almost always a design smell.)

So here are some of the changes:

As I said above these are just notes in a draft state.

Doing a refactoring without test cases is always dangerous...

우리는 디자인 패턴에 대한 리팩토링을 2005년도에 실험했어요.

여기 우리가 회의했던 내용에 대한 약간의 노트가 있습니다.

우리는 객체지향 설계 원칙과 대부분의 패턴들은 그때 이후로 변경된 것이 없다는 걸 알았습니다.

우리는 카테고리를 변경하고 몇몇 새로운 패턴들을 추가하고 몇몇 패턴들을 빼버리려고 했습니다.

대부분의 논의는 카테고리를 바꾸는 것과 어떤 패턴들을 빼버릴 것인가에 관한 것이었어요.

어떤 패턴을 빼버릴까 의논하던 중, 우리는 빼버리려던 그 패턴들 모두를 여전히 사랑하고 있다는 걸 깨달았지요.
(사실 그건 아니고 - 저는 싱글톤은 빼버리는데 동의합니다. 싱글톤의 사용은 거의 항상 나쁜 설계의 냄새거든요.)

그 때 정한 몇 가지 변경사항을 얘기해보면요:

앞서 얘기한 것처럼 이 내용은 단지 드래프트 상태의 노트에 불과합니다.

테스트 케이스없이 리팩토링하는 것은 항상 위험하기 마련이니까요...

휴... (- 3-) =3

어찌되었든...뭐, 이걸로 다 끝내긴 했네요. :)

GoF (Gang Of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) 의

디자인 패턴 책이 나온 지도 어언 15년이 지났다.

Erich Gamma 는 얼마 전 내한하기도 했었는데

현재 IBM Rational Software 에서 Jazz 프로젝트의 리더로 활동 중이다.

Ralph Johnson 역시 얼마 전 내한했으며,

현재 일리노이 어바나-샴페인 대학에서 교수로 재직 중이다.

[사진] OOPSLA '94 에서의 GoF의 모습.

왼쪽부터 Ralph Johnson, Erich Gamma, Richard Helm, John Vlissides.

Richard Helm 은

현재 Boston Consulting Group 이라는 회사의 임원으로 재직 중인 것으로 알려져있다.

John Vlissides 는 안타깝게도 2005년 뇌종양으로 별세하셨다고 한다.

디자인 패턴 책 출간 15주년을 기념하여 informit 에서 GoF 와의 인터뷰 기사를 실었는데...

http://www.informit.com/articles/article.aspx?p=1404056&rll=1

어떻게 된게 몇 날 몇 일을 기다려봐도

누구 하나 멋지게 번역해서 올리는 사람이 없다. ㅠ_ ㅠ

짬짬이 영어 원문 기사를 본다고 보는데

읽을 때마다 반복되는 번역 프로세스로 인해 당최 진도가 나가지 않아... =_ =;;;

할 수 없이 마지못해 허접하나마 직접 번역해서 이렇게 올려보기로 한다.

혹 필요하신 분이 있으시면 슬쩍 보셔도 무방하지만

퀄리티는 결코 책임질 수 없다는 거. -_-)a

다른 분이 더 잘 다듬어서 올려주시면 참 좋겠다는 생각을 끝으로

서론은 여기까지 하기로 하고, 이제 슬슬 본론 들어가야쓰겠다.

Design Patterns 15 Years Later: An Interview

with Erich Gamma, Richard Helm, and Ralph Johnson

Erich Gamma, Richard Helm, and Ralph Johnson
talk to Larry O'Brien about Design Patterns, 15 years later.

Erich Gamma, Richard Helm, Ralph Johnson 이
디자인 패턴 책이 출간된 지 15년이 지난 지금
디자인 패턴에 대해 Larry O'Brien 과 얘기를 나눴습니다.

Larry O'Brien:
85,000 apps for the iPhone have been developed and deployed in the past year-and-change.

One can write a globally-accessible "Hello, World! The time is X" Web page
in just one line of PHP, for instance.

"Designing object-oriented software is hard," are the first words of Design Patterns.
Are those words still accurate?

지난 한 해동안 85,000 개의 아이폰 앱스가 개발되고 배포되었습니다.

예를 들어, 이제는 단 한 줄의 PHP 코드로
전세계 어디서든 접속가능한 "Hello, World! 지금 시간은 X입니다" 라는 웹 페이지를
작성할 수 있게 되었는데요.

"객체지향 소프트웨어를 설계하는 것은 매우 어려운 일이다" 가 디자인 패턴 책의 첫 문장인데
이 얘기가 지금도 여전히 정확한 것인지요?

Richard Helm:
Software design is always hard.

Although most modern development environments do lots
to reduce complexity through reusable libraries and toolkits (Eclipse, Apple, Microsoft),
designing a software solution to the business problem is still hard.

대부분의 현대적인 개발 환경이
재사용 가능한 라이브러리와 툴킷들을 통해 복잡성을 줄여주기 위한 많은 일을 해준다고 할지라도,
비지니스적인 문제 해결을 위한 소프트웨어 솔루션을 설계한다는 것은 여전히 어려운 일입니다.

Erich Gamma:
Yes, and it is funny that you mention the iPhone.

The iPhone SDK is based on the NeXTStep object-oriented frameworks like the AppKit.

It already existed when we wrote Design Patterns 15 years ago
and was one source of inspiration.

We actually refer to this framework in several of our patterns:
Adapter, Bridge, Proxy, and Chain of Responsibility.


그렇습니다, 그리고 아이폰을 예를 드셨는데, 참 재밌군요.

아이폰 SDK는 AppKit 같은 NeXTStep 의 객체지향 프레임워크에 근간을 두고 있습니다.

그런데, 그게 사실은 우리가 15년 전에 디자인 패턴 책을 쓸 때도 이미 있었던 거거든요.
그리고 책을 쓸 때 아이디어를 얻었던 내용 중의 하나이기도 했구요.

Adapter, Bridge, Proxy, Chain of Responsibility 같은 몇몇 패턴의 경우는
실제로 이 프레임워크를 참조했습니다.

Richard:
Which is a great example of the enduring nature of good design,
and how it survives different technical manifestations.


그게 바로 좋은 설계는 오랫동안 유지될 수 있는 성질을 가지고 있고,
다양한 기술들이 나타났다 사라지는 환경 속에서도 좋은 설계는 살아남을 수 있다는 걸 보여주는
훌량한 예라 하겠습니다.

Ralph Johnson:
Writing one-line programs is not usually what we mean by design.

Software has improved a lot over the years,
and a lot of systems that used to require careful design
can now be built by reusing other software.

But there are a lot of systems that we can't build that way,
and writing 100K lines of new code isn't that much easier now
than it was 15 years ago.

It will do a lot more, but costs the same.

Designing software is hard.

That is what makes it so fun!

People who are good at designing software enjoy solving hard problems,
at bringing order to chaos, at overcoming difficulties.

Things that used to be hard are now easy,
but we have moved on to working on problems
that would have been impossible 20 years ago.

OO programming helps but does not eliminate the difficulty of design.

한줄짜리 프로그램을 짜는 것은 사실 우리가 말하려는 설계는 아닙니다.

소프트웨어는 수년동안 엄청나게 개선되어왔고,
주의깊은 설계가 요구되는 시스템이라 할지라도
대다수의 시스템들은 이제는 다른 소프트웨어를 재사용함으로써 만들 수 있게 되었습니다.

그러나, 이런 식으로 만들 수 없는 소프트웨어들도 여전히 많이 남아있습니다.
더구나 십만 줄의 새로운 코드를 짜는 것이
15년 전에 비해 지금도 그렇게 수월한 것은 아니니까요.

분명 그러한 것이 많은 일을 해 주긴 하겠습니다만, 비용은 똑같습니다.

소프트웨어를 설계하는 것은 어렵습니다.
그리고 그 어려움이 이 일을 신나게 만드는 이유죠.

소프트웨어 설계를 잘 하는 사람들, 혼돈의 세상에 질서를 가져다 주는 사람들, 어려움을 극복하는 사람들은
어려운 문제를 푸는 것을 즐깁니다.

예전에는 어려웠던 일들이 지금은 쉬워졌습니다.
그렇지만 이제 우리는 20년 전에는 불가능했을 그런 문제들에 도전하고 있습니다.

객체지행 프로그래밍이 도움이 되는 것은 사실이지만,
그렇다고 설계의 어려움 자체를 없애주지는 않습니다.

Larry:
The next phrase in the book is
"...designing reusable object-oriented software is even harder."

Reuse was, in the early 90s, presented as object-orientation's main benefit.

But in the past decade,
it seems that many mainstream developers
have decided to leave reuse to the framework designers.

Develop what you need today, do the minimal refactoring if you need to evolve it,
and, if questioned, play the "You Ain't Gonna Need It," card.

Is striving for reusable design an important goal for today's developers?

디자인 패턴 책의 다음 구절이
"...재사용 가능한 객체지향 소프트웨어를 설계하는 것은 더욱 어렵다" 입니다.

90년대 초반에는 재사용성이 객체지향의 주요한 장점 중의 하나로 묘사되었는데요.

하지만 지난 10년을 되돌아보면
많은 주류 개발자들은 재사용성을 프레임워크 설계자들한테 떠넘기기로 결심한 것처럼 보이거든요.

당장 지금 필요한 것만 개발하라, 확장할 필요가 있을 때만 약간의 리팩토링을 해라,
그리고 누가 물어보면 "넌 그거 필요 없을거잖아" 라는 카드를 들이밀어라.

재사용 가능한 설계를 얻기 위해 노력하는 것이
오늘날의 개발자들에게도 여전히 중요한 목적이어야 하나요?


Richard:
I think there has been an evolution in level of sophistication.

Reusable software has migrated to the underlying system/language
as toolkits or frameworks -
and mostly should be left to the experts.

The goal for most software developers still remains to design for change -
and there the debate is do you do it early (given foreknowledge)
or later (once more is known and you know you need it)?

In many cases the design should be refactored,
and the patterns provide a target to do this.

제 생각에는 복잡성의 단계에도 점진적으로 변화가 있었던 것이 아닌가 싶습니다.

재사용 가능한 소프트웨어는 툴킷이나 프레임워크와 같은 하부의 시스템과 언어로 이동되었고
주로 전문가들에게 맡겨지게 되었습니다.

대다수 소프트웨어 개발자들의 목표는 여전히 변화에 대응할 수 있는 설계로 남아 있습니다.
그리고 재사용 가능한 설계를 좀 더 일찍할 거냐 (선견지명이 있다면)
아니면 좀 더 나중에 할 거냐에는
(더 많은 내용을 알게되면 재사용 가능한 설계가 필요하다는 것을 알게되니까)
논쟁이 있는 걸로 알고 있습니다.

다만, 대부분의 경우에 설계는 리팩토링되기 마련이고,

패턴은 이를 위한 목표를 제공하는 것이지요.

Erich:
Actually, I'd now add an additional phrase
"... the hardest is evolving reusable object-oriented software."

We touch on this a little bit in Design Patterns.

For example, factories, adapters and facades
can help when it comes to changing and evolving a reusable library.

There are some additional patterns for this problem that would be worthwhile capturing.

I agree that designing durable APIs requires an additional level of sophistication.

Decisions you make today will impact what you can do tomorrow.

However, even experts have a hard time to get it right the first time.

For example, if you dive into the Eclipse APIs
you will find three different versions of the API to store preferences.

사실 저는
"재사용 가능한 객체지향 소프트웨어를 점진적으로 발전시키는 것이 제일 어려운 일이다"
라는 추가적인 문구를 덧붙이고 싶습니다.

우리는 이걸 디자인 패턴에서 조금 다뤘는데요.

예를 들면, 팩토리, 어댑터, 퍼사드 같은 것들은
재사용 가능한 라이브러리를 변경하거나 점진적으로 발전시킬 때
도움이 될 수 있습니다.

오랫동안 유지되는 API를 설계하는 것은 추가적인 복잡성 단계를 요구한다는 점에 동의합니다.

오늘 결정한 사항은 내일 할 수 있는 일에 영향을 주게 되거든요.

그렇지만, 심지어 전문가라고 할지라도 처음에 이걸 제대로 하려면 어렵기 마련입니다.

예를 들면, 이클립스 API로 들어가보면,
preference 를 저장하기 위한 API가 세 가지 버전이 있다는 걸 알 수 있을 겁니다.

Ralph:
Most programmers are not hired to write reusable software,
except in the sense that the software needs to be usable years later,
when requirements change and the world is a different place.

On the other hand, they need to know how reusable software works,
and our patterns are common in reusable software,
so they are still useful for the average programmer to know.

Perhaps it would be better now
to aim the book at people using patterns chosen by others
rather than aim it at people trying to figure out which pattern to use.

대부분 프로그래머들이 재사용 가능한 소프트웨어를 짜기위해 고용되었다기 보다는,
요구사항이 바뀌어 전혀 다른 세상이 되었을 때라도
소프트웨어는 그후 몇 년동안 여전히 사용되어야 할 필요가 있다라는 의미로 봐야 하겠습니다.

반면에, 프로그래머들은 재사용 가능한 소프트웨어가 어떻게 동작하는지 알 필요가 있습니다.
그리고 우리의 패턴들은 재사용 가능한 소프트웨어들의 공통적인 것이구요,
그렇기 때문에 우리의 패턴들은 여전히 보통의 프로그래머들이 알아야할 유용한 것들이지요.

아마 이제는 디자인 패턴 책을
다른 사람들이 선택한 패턴을 그냥 사용하기 위한 목적으로 보기보다는
어떤 패턴을 사용할 건지 고민하는데 도움을 얻기 위해 보는 편이 좋을 것 같습니다.

Erich:
I like this idea.

When I learned the iPhone SDK as I mentioned above,
I noticed that I felt quickly familiar with the library, since I knew the used patterns.

저는 이 생각이 맘에 듭니다.

제가 앞서 얘기한 아이폰 SDK를 배울 때,
제가 라이브러리에 사용된 패턴들을 알고 있었기 때문에
라이브러리에 빨리 친숙해지는 느낌이 든다는 걸 깨달았거든요.

Larry:
For a while, everything became a "pattern."

There were patterns for architecture, organizational behavior, analysis, etc.

What was less apparent, though, was an evolution
where the 23 patterns in the DP catalog
were extended by X other design patterns or related to,
say, architectural patterns.

There are a lot of patterns out there.

Is there a new "Figure 1.1: Design pattern relationships"?

그 동안, 모든 것들이 "패턴"이 되어버렸습니다.

아키텍처, 조직적인 행동, 분석 등을 위한 패턴들도 생겼습니다.

디자인 패턴 카탈로그에 있는 23개의 패턴이
X개의 다른 디자인 패턴들로 확장되거나 그것들과 관련있다고 하는데,
그럴지라도 소위 말하는 아키텍처 패턴으로까지 진화했다라는 것은
좀 불분명한 사실인 것 같습니다.

그렇다고 해도 여전히 세상에는 수많은 패턴들이 있습니다.

"그림 1.1: 디자인 패턴 관계도"에 새로 추가되거나 변경할 내용이 있나요?

[그림 1.1] 디자인 패턴 관계도

Ralph:
If you mean "Do we have a figure to give you?" the answer is "No."
If you mean "Should someone create a new figure?" the answer is "Yes."

"우리보고 디자인 패턴 관계도를 새로 그려줄거냐"고 묻는 거라면 대답은 "아니오" 입니다.
"다른 누군가가 새로운 관계도를 그려야 하느냐"고 묻는 거라면 대답은 "예" 입니다.

Erich:
There is the Patterns Almanac 2000 from Linda Rising
that attempted to capture many patterns.

It was a significant amount of work, but didn't get as much traction in the community.

I start to think that social filtering would help to find out the most popular patterns
and get hints like "people that found this pattern useful have also liked this one...".

In other words, not all patterns have the same relevance and weight.

We were pretty lucky that we picked a good sample of patterns in DP.

Linda Rising 이 많은 패턴들을 기록하고자 시도했던 패턴 연감 2000 이라는 것이 있습니다.

엄청난 분량의 일이었습니다만, 개발자 커뮤니티 사이에서 큰 호응을 이끌어내지는 못했습니다.

저는 가장 인기있는 패턴이 무엇인지 알아내고
"이 패턴을 찾아본 사람들에게 유용한 다른 패턴들"과 같은 힌트를 얻는 데는
소셜 필터링이 도움이 될 수 있다고 생각하기 시작했습니다.

반면, 모든 패턴들이 똑같은 적절성과 중요성을 가지는 것은 아닙니다.

우리는 디자인 패턴 책에서 패턴들 중에 훌륭한 샘플을 골랐었기 때문에
매우 운이 좋았다고 하겠습니다.

Larry:
The description template used in DP had a lot of features beyond Name, Intent, and Structure.

Not everyone who jumped on the patterns bandwagon provided all those elements.

If you were to refactor that template today, what would you do to it?

디자인 패턴 책에서 사용된 패턴 설명을 위한 양식에는
이름, 의도, 구조 등을 넘어 수많은 요소들이 있었습니다.

패턴 열풍에 동참한 모든 사람들이 이러한 모든 요소들을 제공한 것은 아니었는데요.

오늘날 이 양식을 리팩토링한다면, 어떻게 하시겠습니까?

Ralph:
The template was okay for low-level object-oriented patterns like the ones in our book.

It was not good for other purposes.

People quickly found that out and chose different templates.

Every collection of patterns needs a standard template,
but I don't think any template will ever be good for all patterns.

So, I find arguments about templates boring.

그 양식은 디자인 패턴 책에 있는 것같은 하위 레벨의 객체지향 패턴들을 위해서는 괜찮았습니다.

다른 목적을 위해서라면 그다지 못지 못했었죠.

사람들은 이 점을 재빨리 알아채고는 다른 양식들을 사용했어요.

패턴 모음집을 위해서는 어떤 표준 양식이 필요하긴 합니다만,
어떤 양식 하나가 모든 패턴들에 다 좋다라고는 생각지 않습니다.

그래서, 저는 양식에 대한 논쟁은 지루하다고 생각해요.

Erich:
I'm not attached to a particular template.

I'm glad that we eventually agreed on one and then stuck to it.

It helped us to achieve consistency and forced a level of completeness,
e.g., do we have known uses, do we describe the consequences.

저는 특정 양식에 집착하지는 않습니다.

우리는 우연히 어떤 한 양식에 동의했고 그리고는 그 양식을 고수했다는 점이 기쁩니다.

그 점이 일관성을 유지하고 일정 수준의 완결성을 강제하는데 도움이 되었거든요.
예를 들면, 잘 알려진 사용처나 결론 같은 것 말이죠.

- 다음에 계속 -

[번역] 디자인 패턴, 그로부터 15년 후: GoF와의 인터뷰 (2) 로 이어집니다.