티스토리 툴바

BLOG main image
분류 전체보기 (443)
소프트웨어 개발 (146)
크리스찬 (31)
일반 (235)
자녀교육 (12)
나의책읽기 (16)
19,596 Visitors up to today!
Today 130 hit, Yesterday 32 hit
daisy rss
2012/05/10 17:44

People love simple, dependable, adaptable products.

 

When you’re designing any piece of technology, there are at least three perspectives: the manager’s, the engineer’s, and the user’s. This book is about the user’s perspective: it’s about making things feel
simple to use. This book is concerned primarily with the experience of mainstream users.

What mainstreamers want
- Mainstreamers are interested in getting the job done now; experts are interested in customizing their settings first.
- Mainstreamers value ease of control; experts value precision of control.
- Mainstreamers want reliable results; experts want perfect results.
- Mainstreamers are afraid of breaking something; experts want to take things apart to see how they work.
- Mainstreamers want a good match; experts want an exact match.
- Mainstreamers want examples and stories; experts want principles.

 

 Usability aims for…

 Simplicity aims for…

 a specific group of people can use it

 anyone can use it

 easy to use

 effortless to use

 responds quickly  responds instantly
 understood quickly  understood at a glance
 works reliably  works always
 straightforward error messages

 error-free

 complete information

 just enough information

 works in a user test  works in a chaotic environment

 

 

Four strategies for simplicity: Remove, Organize, Hide, Displace
Focus on what’s core. Adding value begins with improving the core experience.

Mapping users’ behavior will help you see how to organize your software.


When the user is directing, and the computer guiding, the experience feels simpler. Computers often make users uncomfortable because they control and direct users’ behavior.

 

저작자 표시 비영리 변경 금지
Trackback Address :: http://booksummary.tistory.com/trackback/544 관련글 쓰기
Tracked from jeopardy powerpoint template | 2012/05/16 12:19 | DEL
김현남의 책 이야기 - Simple and Usable Web, Mobile, and Interaction Design
Tracked from powerpoint template | 2012/05/16 12:20 | DEL
김현남의 책 이야기 - Simple and Usable Web, Mobile, and Interaction Design
Name
Password
Homepage
Secret
2012/04/12 23:25

SW 개발이 무엇인지 정확히 알아야 제대로 된 일을 할 수 있다.

Every Programmer Is a Designer. Everybody who writes software is a designer. Programming has to become the act of reducing complexity to simplicity.

 

SW 설계는 과학이 될 수 있을까? 왜 SW 설계는 과학이 되어야 하는가? 어떻게 SW 설계는 과학이 될 수 있는가? 

저자는 과학이 될 수 있고, 과학이 되어야 한다고 말한다. 과학에 집착하는 이유는 근본 법칙을 발견하기 위해서인것 같다.

What are the fundamental laws of software design?

컴퓨터 과학이 있지 않는가? 저자는 다른 과학을 원한다고 말한다.

The science presented here is not computer science. That’s a mathematical study. Instead, this book contains the beginnings of a science for the “working programmer” a set of fundamental laws and rules to follow when writing a program in any language. This is a science that’s as reliable as physics or chemistry in telling you how to create an application.

 

소프트웨어는 사람들을 돕는 것이다. 계속적으로 도울 수 있어야 한다.

도우는 방법은 시간이 지남에 따라 바뀔 수 있다. 지속적으로 사람들을 도우려면 그러한 변경에 쉽게 대응할 수 있어야 한다. 그렇게 설계해야 한다.

The Goals of Software Design

To allow us to write software that is as helpful as possible.

To allow our software to continue to be as helpful as possible.

To design systems that can be created and maintained as easily as possible by their programmers, so that they can be—and continue to be—as helpful as possible.

 

The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change.

Even if your question is “Should we stay the same and not change?” this equation tells you the answer. Ask yourself “What is the value of staying the same?” and “What is the effort involved in staying the same?” and compare that to the value of changing and the effort involved in changing.

It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.

 

어떤 사람들은 미래를 예측하려고 한다. 미래의 변경을 쉽게 받아들일 수 있도록 하려고 노력한다. 하지만 미래는 예측하기 어렵다. 변경은 발생할 수 밖에 없고, 미래는 예측할 수 없기 때문에 변경을 쉽게 받아들일 수 있도록 하는 것이 중요하다.

So yes, it’s important to remember that there will be a future. But that doesn’t mean you have to predict that future. Instead, it explains why you should be making decisions according to the laws and rules in this book—because they lead to good future software, no matter what that future brings.

 

아무일도 안하면 어떤 문제도 생기지 않을 것이다. 그런데 변경은 발생할 수 밖에 없으니 일을 해야 한다. 일을 해야 하면 문제(결함)가 생긴다. 이것이 설계가 필요한 이유이다. 최고의 설계는 소프트웨어를 가장 적게 바꾸고 대부분의 변경을 수용하도록 하는 것이다.

The funny thing about this law is that it seems to be in conflict with the Law of Change —your software has to change, but changing it will introduce defects. That is a real conflict, and it’s balancing these laws that requires your intelligence as a software designer.
It is actually that conflict that explains why we need design, and in fact tells us what the ideal design is: The best design is the one that allows for the most change in the environment with the least change in the software.

 

한꺼번에 많은 일을 하다보면 그 만큼 문제가 많이 생긴다. 변경이 클 수록 결함의 수는 비례하기 때문에 변경을 작게 하는 것이 중요하다. 개발에 있어 작은 반복이 중요한 이유다. 개발에 있어 작은 반복을 여러번 한다는 것은 첫 번째 반복에서 설계를 하고, 나머지 반복에서 설계변경을 한다는 것이다. 설계에 대해서 가르치는 것도 중요하지만 설계변경에 대해서 가르치는 것은 더 중요하다.

if you want to avoid defects in your code, it does help to keep your changes small.

 

시스템을 구성하는 구성요소들이 단순하면 할 수록 변경은 쉬워진다. 설계변경의 중요한 목표는 시스템 구성요소들을 더 단순하게 만드는 것이다. 

The simpler the pieces are, the more easily you can change things in the future. You have to redesign pieces of the system continuously as new situations and requirements arise.

 

어떻게 단순하게 만들 수 있을까? 단순하다는 것은 상대적인데 어느정도로 해야 단순한 것이 될까? 상대적이라는 것은 컨텍스트가 있다는 것이다. 왜 단순해야 할까? 이해를 쉽게 하기 위해서 단순해야 한다.

Stupid, dumb simple. If your code isn’t stupid, dumb simple to learn, people are going to have trouble
with it.

On the other hand, when you make your product or code stupidly simple, you’re allowing people to understand it. That makes them feel smart, lets them do what they’re trying to do, and doesn’t reflect badly on you at all. In fact, people will probably admire you more if you make things simple than if you make them complex.

 

일관성은 알아야 할 규칙의 수를 줄임으로 쉽게 이해할 수 있도록 한다.   

Consistency is a big part of simplicity. If you do something one way in one place, do it that way in every place.

 

텍스트로 쓰여져 있다면 읽기도 쉬워야 한다.

Readability of code depends primarily on how space is occupied by letters and symbols.

Names should be long enough to fully communicate what something is or does without being so long that they become hard to read.

The real purpose of comments is to explain why you did something, when the reason isn’t obvious.

 

 

왜 복잡해지는가?

원래 복잡할 수 있다.

목적에 맞지 않는 feature가 추가될 때 복잡해진다.

It’s also important to think about the user’s purpose. Your user will be trying to do something. Ideally, the purpose of a program should be very close (in the exact words you’d use to describe it) to the user’s purpose.

Users are happiest with a focused, simple product that never violates its basic purpose.

나쁜 기술을 선택하면 복잡해진다.

오픈소스들이 많이 사용되고 있는 현실에서 기술 선택은 더욱 중요하다. 

There are three factors you can look at to determine if a technology is “bad” before you even start using it: survival potential, interoperability, and attention to quality.

Survival potential(오래 살아남을 수 있어야)

다음과 같은 사항들을 살펴보아야 한다. 

최근 릴리즈 이력, 사용자의 문제를 해결하려는 노력이 있는지, 버그 리포트에 대한 대응을 어떻게 하는지, 메일링 리스트나 지원팀이 능동적으로 활동하고 있는지, 기술이 짧은 시간내에 사라지지 않을 것인지, 벤더가 여럿인지

Interoperability(쉽게 갈아탈 수 있어야)

Ask yourself, “Can we interact with this technology in some standard way, so it would be easy to switch to another system that follows the same standard?”

Attention to Quality(더 나아질 기미가 보여야)

If you can see the source code, check if the developers are refactoring and cleaning up the codebase. Is it becoming easier to use or more complex? Do the people who maintain the technology actually care about the quality of their product? Have there recently been a lot of serious security vulnerabilities in the software that seem like they were the result of poor programming?

설계를 잘못함으로 복잡해질 수 있다.

바퀴를 네모로 설계한다면 자동차를 빠르게 하는 것은 복잡해진다.

문제 정의를 잘못함으로 문제가 복잡해질 수 있다. 다음 질문을 하라.

“What problem are you trying to solve?”

 

어떻게 복잡성을 다룰 것인가? 써봐라. 복잡한 한 조각을 여러 조각으로 나눠라. 쉽게 읽고 이해할 수 있도록 하는 일을 해라. 복잡성을 줄일 수 없다면 숨겨라.

Most difficult design problems can be solved by simply drawing or writing them out on paper.

Each step could be as small as giving a single variable a better name, or just adding a few comments to confusing code. But more often, the steps involve splitting one complex piece into multiple simple pieces.

If you run into an unfixable complexity like this, your goal is to hide the complexity. Put a wrapper around
it that is simple for other programmers to use and understand.

 

잘 돌아가는 지는 해봐야 한다. 변경이 생기면 잘 돌아가는지 확신할 수 없다. 다시 해봐야 한다. 어떻게 하면 성공하는지를 알아야하기도 하지만 어떻게 하면 실패하는지도 알아야 한다.  

The Law of Testing tells us the way out:
The degree to which you know how your software behaves is the degree to which you have accurately tested it.

Unless you’ve tried it, you don’t know that it works.

 

저작자 표시 비영리 변경 금지
Trackback Address :: http://booksummary.tistory.com/trackback/539 관련글 쓰기
Name
Password
Homepage
Secret
2012/04/09 13:25

http://book.naver.com/bookdb/book_detail.nhn?bid=137528

 

이 책은 과학에 관한 철학적 논의들을 소개하려는 의도에서 쓴 책이다.

과학은 우리의 삶에 지대한 영향을 미치고 있기 때문에 과학에 대한 올바른 이해가 중요하다.

 

제 1부. 과학적 방법

제 1장. 귀납과 귀납주의

새로운 도구 - 귀납 - 베이컨

베이컨의 방법은 두 개의 기둥, 즉 관찰과 귀납에 근거하고 있다.

귀납이란 특정한 개별 사례들을 수집한 전체 모집군으로부터 하나의 보편적인 결론을 일반화하는 추리의 형식을 말한다.

 

과학적 방법에 관한 이론이 필요한 이유 중 하나는 과학적 지식이 정당화될 수 있는가의 여부와 정당화될 수 있다면 그 지식의 한계가 어디까지인가를 우리들이 확인할 수 있도록 만들어주기 때문이다.

과학적 방법에 관한 설명을 추구하게 되는 또 다른 이유가 있다. 즉 만약에 우리들이 과학적 방법에 관한 설명을 가지고 있다면 이 설명을 이용하여 어떤 하나의 이론이나 분야가 과학적인지 아닌지를 결정할 수가 있다.

 

3장. 반증주의

과학을 비과학으로부터 구획 짓는 근거들에 관한 이론 - 반증주의 - 포퍼

포퍼는 과학적 방법의 핵심에 있는 것이 확증(confirmation)이 아니라 반증(falsification)이라고 하는 견해에 도달하게 되었다.

포퍼는 근본적으로 과학이란 이론들을 확증하는 것이 아니라 반증하는 것에 관한 것이라고 주장한다.

포퍼는 경험에 의해서 원리적으로 반증이 불가능한 이론은 비과학적이라고 주장하였다.

포퍼는 "우리가 대담한 추측을 더 좋아하는 이유는 시행착오로부터우리들이 배울 수 있는 것이 그러한 추측이라고 믿고 있으며, 우리의 추측이 거짓이라는 것을 발견하는 데서 진리에 대해 더 많은 것을 배우고 진리에 더 가까이 가게 될 것일고 믿기 때문이다."라고 말한다.

포퍼는  "덕목은 오류들을 피하려고 하는 조심성에 있는 것이 아니라 그러한 오류들을 인정사정 보지 않고 제거하려고노력하는 데 있다"라고 말한다.

포퍼가 매력적인 인물로 다가온다. 그래서 그의 책을 한 권 사서 읽었다. [삶은 문제해결의 연속이다]

 

4장. 과학혁명들과 합리성

쿤은 "패러다임들이 변화할 때, 세계는 그와 함께 변화하게 된다"라고 말한다. 이러한 견해에 따르면 서로 다른 이론들의 서로 다른 언어들은 그 각각의 이론들의 세계에 대응하고, 경쟁 패러다임을 지지하는 사람들은 서로 다른 세계에 머물고 있다.

 

2부 과학에 대한 실재론과 반실재론

5장. 과학적 실재론

과학적 실재론은 우리들이 가지고 있는 최선의 과학이론들이 요청하는 관찰할 수 없는 대상들의 존재를 믿어야만 한다고 주장하는 견해이다.

과학혁명과 근대의 과학적인 세계상을 처음으로 만드는 데 노력했던 많은 위대한 사상가들은 속성에 대해 제1속성과 제2속성이라는 두 가지 유형으로 구분하였다.

제1속성은 사물이 가지고 있는 것으로 나타날 뿐만 아니라 사물 자체가 실제로 가지고 있는 [객관적] 속성이다. 제2속성은 사물이 가지고 있는 것으로 나타나지만 실제로는 그 사물에 없고 단지 관찰자의 정신에만 나타나는 [주관적] 속성이다.

표준적인 과학적 실재론

만약 우리들이 어떤 주제 S에 대해 형이상학적이고 의미론적인 실재론을 통합하고 인식적인 요구사항들을 부가한다면 우리들은 S에 대해서 아주 강한 형식의 실제론을 가지게 될 것이다.

1. S에 대한 논의들이 기술하고 있는 대상이나 대상의 종류들은 실제로 존재한다.

2. 이것들은 우리들의 인식과 정신으로부터 독립적으로 존재한다.

이상의 내용은 형이상학적 요구사항들이다.

3. S에 대한 언명들은 환원될 수 없고 제거될 수 없으며, 순수하게 주장적 표현들이다.

4. S의 언명들에 대한 진리 조건들은 객관적이며, 사물들이 세계 속에서 어떠한 상태에 있는가에 따라 이러한 언명들의 진리나 거짓이 결정된다.

이상의 내용들이 의미론적 요구사항들로서 실용주의 진리론이나 진리 정합론에 반대되는 진리 대응론에 의해서만 보장된다.

5. S에 대한 진리는 인식가능하고 우리들은 사실상 그러한 진리의 일부를 인식한다. 그래서 S의 용어들은 세계 속에 있는 사물들을 성공적으로 지시한다.

이러한 내용이 인식적 요구사항이다.

 

무엇에 대한 실재론인가? 그것은 대상들인가, 추상적인 구조적 관계들인가, 기본 법칙들인가, 아니면 무엇이란 말인가? 나는 물리 이론에 대한 '참된' 내용이 되는 최선의 후보자는 추상적인 구조적 측면이라는 견해를 가지고 있다. 이러한 점은 스타인이 표현한 구조적 실재론자의 감정들과 일치하는 것처럼 보인다.

"우리들의 과학은 '실체들'이나 그와 유사한 것에 관한 설명에서가 아니라 현상들이 '모방'하는 '형상들Forms' 에 관한 설명에서 가장 가까이 다가가서 실재적인 것을 포착하게 된다.  여기서 모방은 무엇에 의해 표상된 혹은 표현된의 의미로 해석되고, 형상들은 이론적 구조들로 해석된다.

 

 

지식의 성격과 정당화를 탐구하는 철학의 분야는 보통 인식론(epistemology)이라고 불린다.

지식이란 정당화된 참된 믿음이다.

겉모습[현상]과 실재 간의 이러한 구별이 형이상학에서는 중심문제가 된다. 왜냐하면 형이상학은 사물이 단지 우리들에게 어떻게 나타나느냐가 아니라 '사물 자체가 실제로 존재하는 바대로' 기술하려고 하기 때문이다.

저작자 표시 비영리 변경 금지
Trackback Address :: http://booksummary.tistory.com/trackback/537 관련글 쓰기
Name
Password
Homepage
Secret
prev"" #1 #2 #3 #4 #5 ... #148 next