2021년 11월 24일 수요일

REACT,문제 풀기

REACT,답

REACT,문제

JAVASCRIPT,답

JAVASCRIPT,문제

JAVASCRIPT,문제 풀기

JAVA답

JAVA 문제

JAVA 문제 풀기

SQLD

Computer Science 이론

 Computer Science 이론

Algorithm 문제풀기

 Algorithm 문제풀기

Algorithm 답

 Algorithm 답

Algorithm 문제

 Algorithm 문제

2021년 11월 23일 화요일

[冊] 사용자를 끌어들이는 UX/UI의 비밀

 좋은 인터페이스는 삶을 더 쉽게 만들어야 한다.


정보 설계에서 내비게이션, 액션, 비주얼 디자인까지

사용자를 사로잡는 인터페이스 디자인 기술


(대략 문제 제기)

이 책은 SNS,이미지/영상 편집, 길 찾기를 비롯한 다양한 앱에서부터 

쇼핑, 예약, 금융 웹사이트까지 웹과 모바일을 위한 화면 기반 인터랙션에 최적화된

UX/UI 패턴 80가지를 소개한다. 


원활한 사용자 흐름을 만들고 이용자의 태스크 달성을 돕는 데 효과적인 400 여개를 보여준다.


버즈피드, 슬랙, 어도비 포토샵, 스포티파이, 세일즈포스 등 어떻게 인터페이스를 디자인하는지 체계적으로 설명한다.


=> 패턴의 목적은 새로운 장을 여는 것이 아니라 잘 알려진 언어를 공식화하고 설명하는 것이다.


1. 문제를 정확히 파악하고 제대로 해결하는 디자인 


이번 장을 읽고 나면 웹사이트, 애플리케이션, 인터페이스를 디자인할 때 사용자에게

중요한 게 무엇인지, 아래와 같은 내용을 이해할 수 있을 것이다.


- 웹사이트나 애플리케이션의 사용 목적

- 목적 달성을 위해 거치는 상세 태스크

 - 특정 주제나 도메인에 대한 사용자의 의견

 - 인터페이스에 관해 사용자가 생각하고 사용하는 언어

 - 작업 숙련도에 따른 사용자가 취하는 태도


좋은 인터페이스 디자인은 화면을 그리는 데서 시작하지 않는다.

먼저 사용자를 이해해야 좋은 인터페이스를 디자인 할 수 있다.

소프트웨어를 쓰는 사용자가 어떤 사람이고, 왜 이 소프트웨어를 사용하려 하며,

어떻게 사용하는지를 알아야 한다.


사용자를 더 많이 이해하고 공감할수록, 그들에게 실질적으로 도움이 되는 디자인을

할 수 있다.

결국 소프트웨어는 사용자에게 목적을 달성하는 수단일 뿐이다.


사람을 위한 디자인 프레임워크를 구성하는 4가지 영역


컨텍스트 : 사용자는 누구인가?

목표 : 사용자는 무엇을 하고자 하는가?

리서치 : 사용자의 전후 사정과 목표를 이해하는 방법

패턴 : 인터페이스 디자인과 관련된 사용자 인식과 행동


사용자를 있는 그대로 이해하는 방법


 - 소프트웨어나 웹사이트를 사용하는 목표

 - 목표를 달성하기 위해 수행하는 특정 데스크

 - 무엇을 하고 있는지 묘사하는 데 쓰는 언어와 단어

 - 기존의 유사한 소프트웨어를 사용하는 스킬

 - 기존의 유사한 소프트웨어에 대한 태도와 디자인이 그러한 태도에 미치는 영향


인터페이스에서 사람들은 무슨 생각을 하고 어떻게 행동할까?


패턴을 열광적으로 지지하는 사람들에게 : 

여기서 다루는 패턴은 다른 장에서 소개하는 패턴과 다르다.

사람의 행동을 묘사하는 패턴이지, 인터페이스 디자인 요소가 아니다.

다른 장처럼 디자인을 규정하는 성격이 아니다.

다른 장의 패턴처럼 디자인을 구조화해서 제시하기 보다는, 짤막한 글로 표현한다.


 - 안전한 탐색

 - 즉각적 만족

 - 만족화

 - 중도에 바꾸기

 - 선택 미루기

 - 점진적 창조

 - 습관화

- 짬 시간 활용

 - 공간 기억

 - 미래 계획 기억

 - 능률적 반복

 - 키워드만 사용하기

 - 소셜 미디어, 소셜 프루프, 협업


 - 안전한 탐색

=> "길을 잃거나 곤경에 빠지지 않고 탐험할 수 있게 해줘"

1. 시스템 상황을 보여준다. 

2. 시스템과 현실 세계를 일치시킨다.

3. 사용자에게 통제권과 자유를 부여한다.


=> 사진가가 이미지 처리 애플리케이션에서 몇 가지 필터를 써본다.

필터 적용 결과가 마음에 안 들면, '작업 취소'를 몇 번 클릭해 처음 상태로 되돌아 간다.

=> 회사 홈페이지를 새로 방문하는 사람은 내용을 살펴보려고 여러 링크를 클릭한다.

사용자는 보통 '뒤로 가기' 버튼을 클릭하면 항상 홈 화면으로 돌아갈 것이라 예상한다.

이상적인 경우, 추가 창이나 팝업이 열리지 않고 '뒤로 가기' 버튼도 예상대로 작동할 것이다. 

하지만 만약 웹 앱이 '뒤로 가기' 버튼에 다르게 반응하거나, 애플리케이션에서 '뒤로 가기'

라고 생각한 버튼을 눌렀는데 이전 화면으로 돌아가지 않는다면 사용자는 혼란스러울 것이다.

이럴 때 사용자는 탐색 도중에 길을 잃고 앱 자체를 삭제할 수도 있다.


 - 즉각적 만족

=> "나중에 말고 바로 지금, 이걸 하고 싶어."


사람은 행동을 하면 어떤 결과가 나타나는지 바로 보고 싶어 한다.

이는 인간의 본성이다.

만약 사용자가 애플리케이션을 쓰기 시작한 지 몇 초만에 '성공'을 경험한다면,

얼마나 만족스럽겠는가!

그들은 계속해서 애플리케이션을 사용하고, 심지어 나중에 어려움을 겪어도 계속 쓸 가능성이 높다.

애플리케이션 사용법을 이해하는 데 오래 걸릴 때보다 앱을 자신 있게 사용할 것이다.


 - 만족화

=> "이 정도면 충분해. 더 잘하는 법을 배우는 데 시간을 쓰고 싶지 않아."


 - 중도에 바꾸기

=> "하다가 마음이 바뀌었어."


 - 선택 미루기

=> "지금은 응답하고 싶지 않아, 일단 이걸 완료하게 해줘."


 - 점진적 창조

=> "이 코드 좀 바꿀래. 약간 이상해 보이는데, 다시 바꿀게. 이제 괜찮군!"


 - 습관화

=>"다른 곳에서는 다 작동하는 제스처가 여기서는 왜 안돼?"


- 짬 시간 활용

=> "지금 지하철을 기다리고 있어. 2분 동안 쓸모 있는 일을 하고 싶어."


 - 공간 기억

=> "분명 그 버튼이 1분 전에는 여기 있었는데, 어디 갔지?"


 - 미래 계획 기억

=> "일단 여기에 메모해 두고 나중에 처리하려고."


 - 능률적 반복

=> "이걸 얼마나 반복해야 하지?"


 - 키워드만 사용하기

=> "마우스를 쓰지 않게 해줘."


 - 소셜 미디어, 소셜 프루프, 협업

=> "다른 사람은 어떻게 생각할까?"

2021년 11월 18일 목요일

[冊] 리팩터링

 리팩터링 원칙 > 리팩터링에 대한 저자의 전반적인 견해


리팩터링 정의

리팩터링이란? 소프트웨어의 겉보기 동작은 그대로 유지한 채, 고드를 이해하고 수정하기 쉽도록

내부 구조를 변경하는 기법

>> 리펙터링하다 코드가 깨졌다라고 한다면 그것은 리펙터링이 아니다

restructuring > 재구성

코드 베이스를 정리하거나 구조를 바꾸는 모든 작업

refactoring > 모든 restructuring 중에서 도중에 중단되더라도 동작이 유지되는 것


리팩터링을 하는 이유

1. 소프트웨어 설계가 좋아진다.

2. 소프트웨어를 이해하기 쉬워진다.

3. 버그를 쉽게 찾을 수 있다.

결론 : 프로그래밍 속도를 높일 수 있다.


리팩터링과 성능

리팩터링을 하면서 성능이 저하되면 안된다.

*성능 이슈도 같이 파악할 것


먼저 성능보다 알기 쉽고, 정렬된 코드를 작성한다.

성능 최적화에 대해 프로파일러를 사용하여 분석한다.

로직 중에 소요 시간을 측정하여 개선한다.

(코드 중에 시간 성능에 따라 좋은 코드가 있는데, 해당 부분도 정리할듯)

 - 이 부분을 개선


 YAGNI에 대하여 서술하세요

=> You Aren't Going to Neet It

 - 코딩을 시작하기 전에 아키텍처를 확정해야 한다.

아키텍처를 확정하지 않으면, 요구사항 사전 파악이 불가능하다.

  - 유연성 메커니즘을 심어두면, 오히려 대응 능력을 저해할 수 있다.

이를 YAGNI라고 한다.

=> 추측하지 말고 현재 요구사항에 충실하여 충족시키도록 해야 한다.

=> 대신에 이에 대해 최대한 잘 해결되도록 설계해야 한다.

=> 나중에 이에 대해 더 잘 이해하게 되면, 리팩터링을 활용하여 바꾸어야 한다.


이것은 선제적 아키텍처에 소홀해진다는 의미가 아니다.

이미 알고 있는 부분은 최대한 신경 써서 사전에 준비하는 것이 좋으나,

모르는 부분을 미리 대비하기 보다는, 이해하고 나서 반영하는 것이 효율적이다.


코드에서 악취가 난다?

변수 명의 잘못

=> 변수 명이 영단어 단수 명사로 표기되어야 한다. 3~4자로 약축어를 

사용하는 편이 좋은데, 해당 부분 역시 싸이트 검색을 활용하는 것이 바람직하다.-

=>함수 형태를 활용하여 리팩토링하고, 쪼개기를 하는 것이 좋다.


리팩토링의 정의

리팩토링(Refactoring) - 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록

겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것

리랙토링 하다(Refactoring) - 일련의 리펙토링을 적용하여 겉으로 보이는 동작의 변화 없이 소프트웨어 구조를 바꾸다.

첫째 리팩토링의 목적은 소프트웨어를 보다 이해하기 쉽고, 수정하기 쉽도록 만드는 것이다

둘째 리팩토링은 겉으로 보이는 소프트웨어의 기능을 변경하지 않는다는 것이다


두 개의 모자

두가지 구별된 작업(기능 추가와 리팩토링)을 위해 시간을 나눠야 한다

기능을 추가할 때는 기존 코드를 건드려서는 안되고 단지 새로운 기능만 추가해야 한다

리팩토링을 할 때는 기능을 추가해서는 안되고 단지 코드의 구조에만 신경써야 한다.


왜 리팩토링을 해야 하는가?

리팩토링은 소프트웨어의 디자인을 개선 시킨다.

리팩토링은 소프트웨어를 더 이해하기 쉽게 만든다.

리팩토링은 버그를 찾도록 도와준다.

리팩토링은 프로그램을 빨리 작성하도록 도와준다.


언제 리팩토링을 하는가?

삼진규칙 - 3번 중복되면 그때 리팩토링을 한다.

기능을 추가할 때 리팩토링을 하라

버그를 수정할 때 리팩토링을 하라

코드검토(code review)를 할 때 리팩토링을 하라

관리자에게는 뭐라 말해야 하나?

리팩토링을 할 때의 문제

데이터베이스

인터페이스 변경

리팩토링이 어려운 디자인 변경

언제 리팩토링을 하지 말아야 하는가?


코드속 나쁜 냄새

이제 리팩토링이 어떻게 돌아가는지 잘 알게 되었을 것이다 리팩토링을 언제 시작하고 언제 끝낼지를 결정하는 것은 리팩토링을 어떤 절차에 따라 해야 하는지를 아는 만큼이나 중요하다 인스턴스 변수 하나 삭제하거나 클래스 구조를 만드는 것에 대해 설명하는 것은 쉽다. 프로그램 미학(aesthetics) 같은 모호한 개념에 호소하기 보다는 좀 더 구체적인 것을 원한다.


Kent Beck을 방문했을때 리팩토링을 필요한 시점에 대한 생각을 냄새의 관점에서 설명했다. 냄새 - 정확한 지점을 집어내기 보다는 뭉뚱그려서 찾아냅니다


중복된 코드(Duplicated Code)

한 곳 이상에서 중복된 코드 구조가 나타난다면, 그것을 합쳐서 프로그램을 개선할 수 있다.


한 클래스의 서로 다른 두 메소드 안에 같은 코드가 있는 경우

Extract Method - 뽑아낸 메소드를 두 곳에서 호출하도록 하는 것


동일한 수퍼 클래스를 갖는 두 서브 클래스에서 같은 코드가 있는 경우

양쪽 클래스에서 Extract Method 사용한 다음 Pull Up Method 사용한다


코드가 비슷하기는 하지만 같지는 않다면

비슷한 부분과 서로 다른 부분을 분리하기 위해 Extract Method 사용 후 Form Template Method 사용할 수 있는지 살펴본다


같은 작업을 하지만 다른 알고리즘을 사용한다면

두 알고리즘 중 더 명확한 것을 선택한 다음 Substitute Algorithm을 사용할 수 있다.


서로 관계 없는 두 클래스에서 중복된 코드가 있는 경우

한쪽 클래스에서 Extract Class를 사용한 다음 양쪽에서 이 새로운 클래스를 사용하도록 하는 것 고려

메소드가 클래스 중 하나에 포함되어 있고 다른 클래스에서 호출

세번째 클래스에 속하는 그 메소드가 원래 두 클래스에서 참조되어야 하는 경우


긴 메소드(Long Method)

우리가 따르는 방법은 어떤것에 대해서 주석을 달아야 할 필요를 느낄 때마다 메소드를 작성하는 것이다

메소드의 길이가 아니라 메소드가 하는 일과 일을 처리하는 방법 사이의 의미적 거리(semantic distance)


대부분의 경우 메소드의 길이를 줄이가 위해 해야 하는 경우

Extract Method 사용하자


메소드에 파라미터와 임시변수가 많다면

임시변수는 Replace Temp with Query를 사용할 수 있다

긴 파라미터 리스트는 Introduce Parameter Object, Preserve Whole Object 사용할 수 있다.


여전히 임시변수와 파라미터가 많다면

Replace Method with Method Object라는 중장비를 사용하자


뽑아낼 코드 덩어리의 식별은 주석을 찾는 것이다.조건문과 루프 또한 메소드 추출이 필요하다는 신호를 준다.


조건식을 다루기 위해서는

Decompose Conditional 사용한다.


루프의 경우는 루프와 그 안의 코드를 추출하여 하나의 메소드로 만든다

2021년 11월 10일 수요일

[冊] 사용자를 끌어들이는 UX/UI의 비밀 : 목차

목차

제3판 서문: 인터페이스는 삶을 더 쉽게 만들어야 한다


1장 문제를 정확히 파악하고 제대로 해결하는 디자인


사용자를 둘러싼 컨텍스트 파악하기

_당신은 사용자가 아니다

_인터랙션은 대화처럼

_콘텐츠와 기능을 사용자에게 맞춰라

_숙련도에 따라 달라지는 것들

_인터페이스는 목표를 달성하는 수단일 뿐

_‘왜?’라고 묻고 또 묻기

_문제를 정확히 파악하고 제대로 해결하기

사용자를 있는 그대로 이해하는 법

_직접 관찰

_케이스 스터디

_설문조사

_퍼소나(personas)

_디자인 리서치는 마케팅 리서치가 아니다

인터페이스에서 사람들은 무슨 생각을 하고 어떻게 행동할까?

_안전한 탐색(Safe Exploration)

_즉각적 만족(Instant gratification)

_만족화(Satisficing)

_중도에 바꾸기(Changes in Midstream)

_선택 미루기(Deferred Choices)

_점진적 창조(Incremental Construction)

_습관화(Habituation)

_짬시간 활용(Microbreaks)

_공간 기억(Spatial Memory)

_미래 계획 기억(Prospective Memory)

_능률적 반복(Streamlined Repetition)

_키보드만 사용하기(Keyboard Only)

_소셜 미디어(Social Media), 소셜 프루프(Social Proof), 협업(Collaboration)

성공적인 인터랙션 디자인을 위한 필수 요소


2장 콘텐츠 구성하기: 정보 설계와 애플리케이션 구조


사용에 방해되지 않는 정보 구조 만들기

정보 구조란?

_사용자를 위한 정보 공간

접근법

_정보와 정보의 표현을 분리하라

상호 배타적이면서 전체를 포괄하기

콘텐츠를 구성하고 분류하는 방법

_위치(Location)

_가나다순(Alphabetical)

_시간(Time)

_카테고리(Category) 또는 다면 필터(Facet)

_위계(Hierarchy)

_숫자(Number)

태스크와 작업흐름 위주의 앱 디자인하기

_자주 사용하는 항목을 눈에 띄게 하라

_일련의 단계로 작업 ‘쪼개기’

_다양한 채널과 화면 크기는 우리가 직면해야 하는 현실

_정보를 카드 형태로 보여 줘라

화면 유형의 시스템 디자인

개요 보기: 목록이나 그리드 위에서 항목과 옵션 보여 주기

집중하기: 한 번에 하나만 표시하기

만들기: 창작을 위한 툴 제공하기

수행하기: 하나의 태스크를 효과적으로 완료하기

패턴

_01 추천(Feature), 검색(Search), 탐색(Browse)

_02 모바일 다이렉트 액세스(Mobile Direct Access)

_03 스트림(Streams)과 피드(Feeds)

_04 미디어 브라우저(Media Browser)

_05 대시보드(Dashboard)

_06 캔버스(Canvas)와 팔레트(Palette)

_07 마법사(Wizard)

_08 설정 편집기(Settings Editor)

_09 다양한 보기 모드(Alternative Views)

_10 작업 공간 나누기(Many Workspaces)

_11 도움말 시스템(Help Systems)

_12 태그(Tags)

유연하면서도 단단한 정보 구조를 만들자


3장 이동하기: 표지판, 길 찾기, 내비게이션


정보와 태스크 공간 이해하기

표지판

길 찾기

내비게이션

_글로벌 내비게이션(Global Navigation)

_유틸리티 내비게이션(Utility Navigation)

_연관 및 인라인 내비게이션(Associative and Inline Navigation)

_관련 콘텐츠(Related Content)

_태그(Tags)

_소셜(Social)

디자인할 때 고려할 점

_내비게이션 디자인과 시각적 표현 분리하기

_인지 부담

_이동 거리 최소화하기

내비게이션 모델

_허브 앤 스포크(Hub and Spoke)

_완전히 연결된(Fully Connected) 모델

_멀티레벨(Multilevel) 또는 트리(Tree)

_단계별 모델

_피라미드 모델

_넓고 얕은 내비게이션

패턴

_13 명확한 진입점(Clear Entry Points)

_14 메뉴 페이지(Menu Page)

_15 피라미드(Pyramid)

_16 모달 패널(Modal Panel)

_17 딥링크(Deep Link)

_18 탈출구(Escape Hatch)

_19 메가 메뉴(Fat Menu)

_20 사이트맵 푸터(Sitemap Footer)

_21 로그인 툴(Sign-In Tools)

_22 프로그레스 인디케이터(Progress Indicator)

_23 브레드크럼(Breadcrumbs)

_24 주석이 붙은 스크롤바(Annotated Scroll Bar)

_25 전환 애니메이션(Animated Transition)

변함없는 가치를 전달하는 내비게이션


4장 화면 구성 요소의 레이아웃


레이아웃의 기본

_시각적 계층 구조(Visual Hierarchy)

_시각적 계층 구조 적용하기

_물체의 중요도 가늠하기

_게슈탈트 법칙 4가지

_시선의 흐름(Visual Flow)

_동적인 디스플레이 사용하기

_반응형 활성화

_단계적 정보 공개

_사용자 인터페이스 영역

패턴

_레이아웃

_정보 분리하기

_26 시각적 프레임워크(Visual Framework)

_27 센터 스테이지(Center Stage)

_28 균등한 그리드(Grid of Equals)

_29 제목을 붙인 섹션(Titled Sections)

_30 모듈 탭(Module Tabs)

_31 아코디언(Accordion)

_32 접히는 패널(Collapsible Panels)

_33 이동식 패널(Movable Panels)


5장 비주얼 스타일과 아름다움


비주얼 디자인의 기초

_시각적 계층 구조

_구성

_색상

_타이포그래피

_가독성

_감정 불러일으키기

_이미지

기업용 애플리케이션을 위한 시각 디자인

_접근성

다양한 비주얼 스타일

_스큐어모픽(Skeuomorphic)

_일러스트

_플랫 디자인(Flat Design)

_미니멀리즘

_적응형/매개변수형 디자인

아름다움이 가진 힘을 과소평가하지 말라


6장 모바일 인터페이스


모바일 디자인의 어려움과 기회 영역

_작은 화면 크기

_다양한 화면 너비

_터치 스크린

_문자 입력하기

_물리적 환경의 제약

_위치 인식

_사회적 영향과 집중력의 한계

모바일 디자인에 접근하는 방법

_모바일 사용자에게 무엇이 필요할까?

_웹/앱을 본질에 맞게 발라내기

_모바일 기기의 하드웨어 활용하기

_콘텐츠를 선형으로 배치하기

_가장 일반적인 인터랙션 시퀀스 최적화

_소개할 만한 좋은 사례들

패턴

_34 버티컬 스택(Vertical Stack)

_35 필름스트립(Filmstrip)

_36 터치 툴(Touch Tools)

_37 하단 내비게이션(Bottom Navigation)

_38 컬렉션(Collections)과 카드(Cards)

_39 무한 리스트(Infinite List)

_40 넉넉한 터치 영역(Generous Borders)

_41 로딩(Loading) 또는 프로그레스 인디케이터(Progress Indicators)

_42 유기적인 앱 연동(Richly Connected Apps)

모바일화하기


7장 목록 만들기


목록의 유스케이스

정보 구조 떠올려 보기

무엇을 보여 줄 것인가?

_선택된 항목 세부사항 표시하기

_무거운 시각 요소 보여 주기

_아주 긴 목록 관리하기

_카테고리나 계층으로 정리된 목록 표시하기

패턴

_43 2분할 패널(Two-Panel Selector) 또는 분할 화면(Split View)

_44 단일 화면 상세 진입(One-Window Drilldown)

_45 포괄 목록(List Inlay)

_46 카드(Cards)

_47 섬네일 그리드(Thumbnail Grid)

_48 캐러셀(Carousel)

_49 페이지네이션(Pagination)

_50 항목으로 즉시 이동하기(Jump to Item)

_51 문자/숫자 스크롤바(Alpha/Numeric Scroller)

_52 신규 항목 추가 행(New-Item Row)

수많은 목록들


8장 작업하기: 동작과 명령


탭(Tap), 스와이프(Swipe), 핀치(Pinch)

회전(Rotate)과 흔들기(Shake)

버튼(Buttons)

메뉴바(Menu Bars)

팝업 메뉴(Pop-Up Menus)

드롭다운 메뉴(Drop-Down Menus)

툴바(Tool bars)

링크(Links)

조작 패널(Action Panels)

호버 툴(Hover Tools)

한 번 클릭하기 vs. 더블 클릭하기

키보드 조작(Keyboard Actions)

_단축키 370

_탭 이동(Tab Order) 370

드래그 앤 드롭(Drag-and-Drop)

텍스트 명령(Typed Commands)

어포던스(Affordance)

객체 직접 조작(Direct Manipulation of Objects)

패턴

_53 버튼 그룹(Button Groups)

_54 호버(Hover) 또는 팝업 툴(Pop-Up Tools)

_55 조작 패널(Action Panel)

_56 완료 버튼 강조(Prominent Done Button)

_57 지능형 메뉴 항목(Smart Menu Items)

_58 미리 보기(Preview)

_59 스피너(Spinner)와 로딩 인디케이터(Loading Indicator)

_60 취소 가능성(Cancelability)

_61 다단계 실행 취소(Multilevel Undo)

_62 명령 기록(Command History)

_63 매크로(Macros)

가장 중요한 동작이 제일 잘 보이게


9장 복잡한 데이터 보여 주기


인포그래픽의 기초

_데이터를 구성하는 조직 모델

_전주의적(preattentive) 변수의 힘

_데이터 탐험하기

_데이터 재배열하기

_검색과 필터링으로 필요한 데이터만 보기

_특정 데이터값이 궁금할 때

패턴

_64 데이터팁(Datatip)

_65 데이터 스포트라이트(Data Spotlight)

_66 동적 쿼리(Dynamic Queries)

_67 데이터 브러싱(Data Brushing)

_68 다중 Y축 그래프(Multi-Y Graph)

_69 스몰 멀티플즈(Small Multiples)

데이터 시각화의 힘


10장 사용자에게 입력값 받기: 폼과 컨트롤


폼 디자인의 기초

_폼 디자인은 계속 진화한다

_더 읽을거리

패턴

_70 자유도가 높은 폼(Forgiving Format)

_71 구조화된 폼(Structured Format)

_72 빈칸 채우기(Fill-in-the-Blanks)

_73 입력 힌트(Input Hints)

_74 입력 프롬프트(Input Prompt)

_75 암호 보안 수준 표시(Password Strength Meter)

_76 자동 완성(Autocompletion)

_77 드롭다운 선택창(Drop-down Chooser)

_78 목록 편집창(List Builder)

_79 적절한 기본값(Good Defaults)과 지능형 사전 입력(Smart Prefills)

_80 오류 메시지(Error Messages)

하면 할수록 어려운 폼 디자인


11장 사용자 인터페이스 시스템과 아토믹 디자인


UI 시스템 트렌드

_마이크로소프트의 플루언트 디자인 시스템

확장 가능한 일관된 인터페이스 설계하기

_아토믹 디자인 개요

_아토믹 디자인 계층 구조

UI 프레임워크는 천장이 아니라 바닥이다

_개요

_장점

_UI 프레임워크의 대두

_대표적인 UI 프레임워크 살펴보기

왜 아토믹 디자인인가?


12장 화면의 이면 그리고 화면을 넘어서


스마트 시스템의 재료

_인터넷 연결 기기(Connected Devices)

_선행 시스템(Anticipatory Systems)

_보조 시스템(Assistive Systems)

_내추럴 사용자 인터페이스(Natural User Interfaces)

변하지 않는 패턴과 원칙

[冊] 도널드 노먼의 디자인과 인간 심리 : 목차

 목차

역자 서문

개정판 서문


제1장 생활용품의 정신병리학

현대 기기의 복잡성

인간 중심 디자인

상호작용의 기초 원칙

시스템 이미지

기술의 역설

디자인이라는 도전


제2장 일상 행위의 심리학

사람들은 어떻게 일을 하는가: 실행과 평가의 간격

행위의 일곱 단계

인간 사고: 대체로 잠재의식적

인간 인지와 정서

행위의 일곱 단계와 세 처리 수준

사람은 이야기꾼이다

엉뚱한 것 탓하기

자신을 잘못 탓하기

행위의 일곱 단계: 일곱 가지 기본적인 디자인 원칙


제3장 머릿속의 지식과 세상 속의 지식

부정확한 지식으로 정확한 행동하기

기억은 머릿속에 있는 지식이다

기억의 구조

근사 모형: 실제 세계에서의 기억

머릿속에 있는 지식

세상 속의 지식과 머릿속의 지식 간의 교환 관계

여러 머리, 여러 기기에서의 기억

자연스러운 대응

문화와 디자인: 자연스러운 대응은 문화에 따라 다를 수 있다


제4장 할 일 알기: 제약, 발견 가능성, 피드백

네 종류의 제약: 물리적·문화적·의미적·논리적

일상용품에 대한 행위 지원성, 기표 및 제약의 적용

원하는 행동을 강제하는 제약

관습, 제약 및 행위 지원성

수도꼭지: 디자인의 사례사

소리를 기표로 사용하기


제5장 인간 오류? 아니, 나쁜 디자인

오류가 생기는 이유의 이해

고의적 위반

두 종류의 오류: 실수와 착오

실수의 분류

착오의 분류

사회적·제도적 압력

오류의 보고

오류의 탐지

오류를 대비한 디자인

좋은 디자인으로 충분하지 않을 때

탄력성 공학

자동화의 역설

오류를 다루는 디자인 원칙


제6장 디자인 생각하기

맞는 문제 해결하기

디자인의 이중 다이아몬드 모형

인간 중심 디자인 과정

방금 내가 말한 것? 실제로 그런 식으로 작동하지 않아

디자인 도전

복잡성은 좋다, 나쁜 것은 혼란이다

표준화와 기술

일부러 일을 어렵게 만들기

디자인: 사람을 위한 기술 개발


제7장 비즈니스 세계의 디자인

경쟁적인 힘

새로운 기술은 변화를 강요한다

새 제품을 도입하는 데 얼마나 오래 걸리는가

두 가지 형태의 혁신: 점진적 그리고 급진적

일상용품 디자인: 1988~2038년

책의 미래

디자인의 윤리적 의무

디자인 생각하기와 디자인에 대해 생각하기


일반적 읽을거리와 주

[冊] 전설로 떠나는 월가의 영웅

[冊] 이펙티브 자바 : 목차

목차

1장 들어가기


2장 객체 생성과 파괴

아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라

아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라

아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라

아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라

아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

아이템 6. 불필요한 객체 생성을 피하라

아이템 7. 다 쓴 객체 참조를 해제하라

아이템 8. finalizer와 cleaner 사용을 피하라

아이템 9. try-finally보다는 try-with-resources를 사용하라


3장 모든 객체의 공통 메서드

아이템 10. equals는 일반 규약을 지켜 재정의하라

아이템 11. equals를 재정의하려거든 hashCode도 재정의하라

아이템 12. toString을 항상 재정의하라

아이템 13. clone 재정의는 주의해서 진행하라

아이템 14. Comparable을 구현할지 고려하라


4장 클래스와 인터페이스

아이템 15. 클래스와 멤버의 접근 권한을 최소화하라

아이템 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

아이템 17. 변경 가능성을 최소화하라

아이템 18. 상속보다는 컴포지션을 사용하라

아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

아이템 20. 추상 클래스보다는 인터페이스를 우선하라

아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라

아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라

아이템 23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라

아이템 24. 멤버 클래스는 되도록 static으로 만들라

아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라


5장 제네릭

아이템 26. 로 타입은 사용하지 말라

아이템 27. 비검사 경고를 제거하라

아이템 28. 배열보다는 리스트를 사용하라

아이템 29. 이왕이면 제네릭 타입으로 만들라

아이템 30. 이왕이면 제네릭 메서드로 만들라

아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라

아이템 33. 타입 안전 이종 컨테이너를 고려하라


6장 열거 타입과 애너테이션

아이템 34. int 상수 대신 열거 타입을 사용하라

아이템 35. ordinal 메서드 대신 인스턴스 필드를 사용하라

아이템 36. 비트 필드 대신 EnumSet을 사용하라

아이템 37. ordinal 인덱싱 대신 EnumMap을 사용하라

아이템 38. 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라

아이템 39. 명명 패턴보다 애너테이션을 사용하라

아이템 40. @Override 애너테이션을 일관되게 사용하라

아이템 41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라


7장 람다와 스트림

아이템 42. 익명 클래스보다는 람다를 사용하라

아이템 43. 람다보다는 메서드 참조를 사용하라

아이템 44. 표준 함수형 인터페이스를 사용하라

아이템 45. 스트림은 주의해서 사용하라

아이템 46. 스트림에서는 부작용 없는 함수를 사용하라

아이템 47. 반환 타입으로는 스트림보다 컬렉션이 낫다

아이템 48. 스트림 병렬화는 주의해서 적용하라


8장 메서드

아이템 49. 매개변수가 유효한지 검사하라

아이템 50. 적시에 방어적 복사본을 만들라

아이템 51. 메서드 시그니처를 신중히 설계하라

아이템 52. 다중정의는 신중히 사용하라

아이템 53. 가변인수는 신중히 사용하라

아이템 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라

아이템 55. 옵셔널 반환은 신중히 하라

아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라


9장 일반적인 프로그래밍 원칙

아이템 57. 지역변수의 범위를 최소화하라

아이템 58. 전통적인 for 문보다는 for-each 문을 사용하라

아이템 59. 라이브러리를 익히고 사용하라

아이템 60. 정확한 답이 필요하다면 float와 double은 피하라

아이템 61. 박싱된 기본 타입보다는 기본 타입을 사용하라

아이템 62. 다른 타입이 적절하다면 문자열 사용을 피하라

아이템 63. 문자열 연결은 느리니 주의하라

아이템 64. 객체는 인터페이스를 사용해 참조하라

아이템 65. 리플렉션보다는 인터페이스를 사용하라

아이템 66. 네이티브 메서드는 신중히 사용하라

아이템 67. 최적화는 신중히 하라

아이템 68. 일반적으로 통용되는 명명 규칙을 따르라


10장 예외

아이템 69. 예외는 진짜 예외 상황에만 사용하라

아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

아이템 71. 필요 없는 검사 예외 사용은 피하라

아이템 72. 표준 예외를 사용하라

아이템 73. 추상화 수준에 맞는 예외를 던지라

아이템 74. 메서드가 던지는 모든 예외를 문서화하라

아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라

아이템 76. 가능한 한 실패 원자적으로 만들라

아이템 77. 예외를 무시하지 말라


11장 동시성

아이템 78. 공유 중인 가변 데이터는 동기화해 사용하라

아이템 79. 과도한 동기화는 피하라

아이템 80. 스레드보다는 실행자, 태스크, 스트림을 애용하라

아이템 81. wait와 notify보다는 동시성 유틸리티를 애용하라

아이템 82. 스레드 안전성 수준을 문서화하라

아이템 83. 지연 초기화는 신중히 사용하라

아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라


12장 직렬화

아이템 85. 자바 직렬화의 대안을 찾으라

아이템 86. Serializable을 구현할지는 신중히 결정하라

아이템 87. 커스텀 직렬화 형태를 고려해보라

아이템 88. readObject 메서드는 방어적으로 작성하라

아이템 89. 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라

아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라


[冊] N잡러 시대의 슬기로운 직장 생활

[冊] 자바스크립트를 말하다

[冊] 프로가 되기 위한 웹 기술 입문

2021년 11월 4일 목요일

[冊] 리팩터링 : 목차

CHAPTER 01 리팩터링: 첫 번째 예시

1.1 자, 시작해보자!

1.2 예시 프로그램을 본 소감

1.3 리팩터링의 첫 단계

1.4 statement() 함수 쪼개기

1.5 중간 점검: 난무하는 중첩 함수

1.6 계산 단계와 포맷팅 단계 분리하기

1.7 중간 점검: 두 파일(과 두 단계)로 분리됨

1.8 다형성을 활용해 계산 코드 재구성하기

1.9 상태 점검: 다형성을 활용하여 데이터 생성하기

1.10 마치며


CHAPTER 02 리팩터링 원칙

2.1 리팩터링 정의

2.2 두 개의 모자

2.3 리팩터링하는 이유

2.4 언제 리팩터링해야 할까?

2.5 리팩터링 시 고려할 문제

2.6 리팩터링, 아키텍처, 애그니(YAGNI)

2.7 리팩터링과 소프트웨어 개발 프로세스

2.8 리팩터링과 성능

2.9 리팩터링의 유래

2.10 리팩터링 자동화

2.11 더 알고 싶다면


CHAPTER 03 코드에서 나는 악취

3.1 기이한 이름

3.2 중복 코드

3.3 긴 함수

3.4 긴 매개변수 목록

3.5 전역 데이터

3.6 가변 데이터

3.7 뒤엉킨 변경

3.8 산탄총 수술

3.9 기능 편애

3.10 데이터 뭉치

3.11 기본형 집착

3.12 반복되는 switch문

3.13 반복문

3.14 성의 없는 요소

3.15 추측성 일반화

3.16 임시 필드

3.17 메시지 체인

3.18 중개자

3.19 내부자 거래

3.20 거대한 클래스

3.21 서로 다른 인터페이스의 대안 클래스들

3.22 데이터 클래스

3.23 상속 포기

3.24 주석


CHAPTER 04 테스트 구축하기

4.1 자가 테스트 코드의 가치

4.2 테스트할 샘플 코드

4.3 첫 번째 테스트

4.4 테스트 추가하기

4.5 픽스처 수정하기

4.6 경계 조건 검사하기

4.7 끝나지 않은 여정


CHAPTER 05 리팩터링 카탈로그 보는 법

5.1 리팩터링 설명 형식

5.2 리팩터링 기법 선정 기준


CHAPTER 06 기본적인 리팩터링

6.1 함수 추출하기

6.2 함수 인라인하기

6.3 변수 추출하기

6.4 변수 인라인하기

6.5 함수 선언 바꾸기

6.6 변수 캡슐화하기

6.7 변수 이름 바꾸기

6.8 매개변수 객체 만들기

6.9 여러 함수를 클래스로 묶기

6.10 여러 함수를 변환 함수로 묶기

6.11 단계 쪼개기


CHAPTER 07 캡슐화

7.1 레코드 캡슐화하기

7.2 컬렉션 캡슐화하기

7.3 기본형을 객체로 바꾸기

7.4 임시 변수를 질의 함수로 바꾸기

7.5 클래스 추출하기

7.6 클래스 인라인하기

7.7 위임 숨기기

7.8 중개자 제거하기

7.9 알고리즘 교체하기


CHAPTER 08 기능 이동

8.1 함수 옮기기

8.2 필드 옮기기

8.3 문장을 함수로 옮기기

8.4 문장을 호출한 곳으로 옮기기

8.5 인라인 코드를 함수 호출로 바꾸기

8.6 문장 슬라이드하기

8.7 반복문 쪼개기

8.8 반복문을 파이프라인으로 바꾸기

8.9 죽은 코드 제거하기


CHAPTER 09 데이터 조직화

9.1 변수 쪼개기

9.2 필드 이름 바꾸기

9.3 파생 변수를 질의 함수로 바꾸기

9.4 참조를 값으로 바꾸기

9.5 값을 참조로 바꾸기

9.6 매직 리터럴 바꾸기


CHAPTER 10 조건부 로직 간소화

10.1 조건문 분해하기

10.2 조건식 통합하기

10.3 중첩 조건문을 보호 구문으로 바꾸기

10.4 조건부 로직을 다형성으로 바꾸기

10.5 특이 케이스 추가하기

10.6 어서션 추가하기

10.7 제어 플래그를 탈출문으로 바꾸기


CHAPTER 11 API 리팩터링

11.1 질의 함수와 변경 함수 분리하기

11.2 함수 매개변수화하기

11.3 플래그 인수 제거하기

11.4 객체 통째로 넘기기

11.5 매개변수를 질의 함수로 바꾸기

11.6 질의 함수를 매개변수로 바꾸기

11.7 세터 제거하기

11.8 생성자를 팩터리 함수로 바꾸기

11.9 함수를 명령으로 바꾸기

11.10 명령을 함수로 바꾸기

11.11 수정된 값 반환하기

11.12 오류 코드를 예외로 바꾸기

11.13 예외를 사전확인으로 바꾸기


CHAPTER 12 상속 다루기

12.1 메서드 올리기

12.2 필드 올리기

12.3 생성자 본문 올리기

12.4 메서드 내리기

12.5 필드 내리기

12.6 타입 코드를 서브클래스로 바꾸기

12.7 서브클래스 제거하기

12.8 슈퍼클래스 추출하기

12.9 계층 합치기

12.10 서브클래스를 위임으로 바꾸기

12.11 슈퍼클래스를 위임으로 바꾸기


부록 A 리팩터링 목록

부록 B 악취 제거 기법

[冊] 독학으로 합격하라

[冊] 회사어로 말하라

[冊] 하루 30분의 힘