Algorithm

 문제 해결 가능성이라는 이론적인 측면에서 알고리즘은 4가지의 조건(입출력, 명확성, 유한성, 유효성)을 모두 만족해야 한다(①-유효성, ②-명확성, ③-유한성, ④-입출력). 

특히 입출력 조건은 0개 이상의 외부 입력과 하나 이상의 출력이 있어야 한다는 것으로, 외부 입력은 존재하지 않아도 무관하므로 보기 ④의 설명이 적절하지 못하다.

한편, 알고리즘의 실용적인 측면까지 고려한다면 알고리즘이 효율적이어야 한다는 조건도 필요하다.

주어진 문제의 종류와 조건 등의 다양성 때문에 범용적인 알고리즘 설계 기법은 존재하지 않으나, 비교적 간단하면서도 많은 부류의 문제에 적용 가능한 대표적인 설계 기법으로는 분할정복 방법(교재 2장), 동적 프로그래밍 방법(교재 3장), 욕심쟁이 방법(교재 4장)이 있다.

입력으로 사용되는 데이터의 크기(“입력 크기”)가 증가하면 그에 따라 당연히 수행 시간도 증가한다. 

따라서 단순히 수행되는 단위 연산의 개수가 아닌 입력 크기 n에 대한 함수로서 시간 복잡도를 표현한다.

f(n)=2n3+3n2-n+10이라고 하고 g(n)=n3이라고 하자.

n>3에 대하여 f(n)≥2g(n)일 때 f(n)을 나타내는 점근적 표기법은?

1

f(n)=O(n3)

2

f(n)=Ω(n3) 

3

f(n)=Θ(n3)

4

f(n)=o(n3)

정답입니다.

정답 : 2

3보다 큰 모든 입력 크기 n에 대해서 f(n)이 2g(n)보다 크거나 같다는 것은 결국 g(n)이 더 이상 작아질 수 없는 점근적 하한을 의미하고, 점근적 하한에 해당하는 표기법은 Big-omega이다. 

참고로 Big-oh 표기법은 점근적 상한(f(n)≤cg(n)), Big-theta 표기법은 점근적 상하한(c1g(n)≤f(n)≤c2g(n))을 의미한다.

알고리즘의 시간 복잡도를 점화식으로 표현하였을 때 가장 효율적인 알고리즘에 해당하는 것은?

1

T(n) = 2T(n/2) + Θ(n), T(1)=Θ(1)

2

T(n) = T(n-1) + Θ(n), T(1)=Θ(1)

3

T(n) = T(n/2) + Θ(1), T(1)=Θ(1)

4

T(n) = T(n/2) + Θ(n), T(1)=Θ(1)

정답입니다.

정답 : 3

각 보기에 해당하는 점화식의 폐쇄형을 차례대로 계산하면 Θ(nlogn), Θ(n2), Θ(logn), Θ(n)이 된다. 

또한, O-표기 간의 연산 시간의 크기 관계에서 오른쪽에 해당할수록 상대적으로 효율성이 나쁜 것을 의미한다.

O(1) < O(logn) < O(n) < O(nlogn) < O(n2) < O(n3) < O(2n)

따라서 Θ(nlogn), Θ(n2), Θ(logn), Θ(n) 중에서 가장 효율성이 좋은 것은 결국 O(logn)이며, 이에 해당하는 보기 ③의 점화식은 이진 탐색의 수행 시간을 나타낼 때 사용된다.

정리하기

[ 컴퓨터 알고리즘이란? ]

▶ 주어진 문제의 결과를 생성하기 위해 모호하지 않고 간단하며 컴퓨터가 수행 가능한 일련의 유한개의 명령을 순서적으로 구성한 것

▶ 조건(입출력, 명확성, 유한성, 유효성) + 실용적 관점에서의 추가 조건(효율성)

▶ 생성 과정 : 설계 → 표현(기술) → 정확성 분석 → 효율성 분석

[ 알고리즘의 설계 ]

▶ 주어진 문제와 조건 등이 매우 다양하므로 모든/대부분 문제에 적용할 수 있는 설계 방법론은 존재하지 않지만, 많은 부류의 문제에 적용될 수 있는 대표적인 설계 기법으로는 분할정복 방법, 동적 프로그래밍 방법, 욕심쟁이 방법이 있음

[ 알고리즘 분석 ]

▶ 정확성 분석: 유효한 입력이 주어졌을 때 유한 시간 내에 정확한 결과를 생성하는지를 판단 → 수학적 기법을 사용해서 이론적으로 증명

▶ 효율성 분석: 공간 복잡도(알고리즘 수행에 필요한 메모리양), 시간 복잡도(알고리즘을 실행시켜 완료될 때까지 걸리는 시간)

▶ 시간 복잡도: 알고리즘에서 수행되는 단위 연산의 수행 횟수의 합으로 표현 → 최악의 수행 시간을 입력 크기의 함수로 표현

[ 점근성능 ]

▶ 입력 크기 n이 무한히 커짐에 따라 결정되는 성능 → 수행 시간의 다항식 함수에서 최고차항만을 계수 없이 취해서 표현 → 알고리즘의 수행 시간의 증가 추이를 나타내는 것으로 알고리즘의 우열 관계를 따질 때 용이

▶ 표기법 : ① “Big-oh” 점근적 상한 f(n) = O(g(n)), ② “Big-omega” 점근적 하한 f(n)=Ω(g(n)), ③ “Big-theta” 점근적 상하한 f(n)=Θ(g(n))

▶ O-표기 간의 연산 시간의 크기 관계 : O(1) < O(logn) < O(n) < O(nlogn) < O(n2) < O(n3) < O(2n)

[ 순환 알고리즘의 성능 ]

▶ 분할정복 방법을 적용한 알고리즘은 기본적으로 순환 알고리즘의 형태로 표현되고, 순환 알고리즘의 성능은 점화식으로 표현됨

▶ 기본 점화식과 폐쇄형

① T(n) = T(n-1) + Θ(1), T(1)=Θ(1) → Θ(n)

② T(n) = T(n-1) + Θ(n), T(1)=Θ(1) → Θ(n2) → 퀵 정렬의 최악 수행 시간

③ T(n) = T(n/2) + Θ(1), T(1)=Θ(1) → Θ(logn) → 이진 탐색의 수행 시간

④ T(n) = T(n/2) + Θ(n), T(1)=Θ(1) → Θ(n)

⑤ T(n) = 2T(n/2) + Θ(1), T(1)=Θ(1) → Θ(n)

⑥ T(n) = 2T(n/2) + Θ(n), T(1)=Θ(1) → Θ(nlogn) → 퀵 정렬의 최선 수행 시간, 합병 정렬의 수행 시간

Algorithm

높이가 h인 포화 이진 트리의 노드 개수는 2h-1이고, 이중 단말 노드의 개수는 2h-1이고, 비단말노드의 개수는 2h-1-1이다.

▶ 차수 → 해당 정점에 부수된 간선의 개수이며, 방향 그래프에서는 정점으로 들어오는 간선의 수를 진입 차수라고 하고 해당 정점에서 나가는 간선의 수를 진출 차수라고 한다.

▶ 경로의 길이 → 경로에 존재하는 간선의 개수라고 한다.

▶ 깊이 또는 높이 → 트리에 속하는 노드 중에서 가장 큰 레벨(레벨≥0)에 1을 더한 것을 의미한다.

① 연결 리스트보다 배열은 삽입과 삭제 시 추가적인 자료의 이동이 필요하다.

② 그래프에서 정점에 부수된 간선의 개수를 차수라고 한다.

④ 두 정점 u와 v 사이에 간선이 있으면 정점 u와 v는 인접한다고 표현한다.

필수 い 형용사 (보통형, 변형, 명사 수식)

 

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

생활용품의 정신병리학

좋은 디자인의 가장 중요한 특성 중 두 가지는 발견 가능성과 이해이다.

발견 가능성, 즉 어떤 행동이 가능한지, 그 일을 어디에서 어떻게 할 수 있는지를

알아내는 것이 가능한가?

이해, 즉 이것이 도대체 무슨 뜻인가?

제품이 어떻게 쓰라고 만들어진 것인가?

이 모든 여러 조절기와 설정이 무슨 뜻인가?

현대 기기의 복잡성

산업 디자인 : 사용자와 생산자 모두의 상호 이익을 위해 제품과 시스템의 기능, 가치 및 외관을

최적화하는 개념과 명세사항을 만들어 내고 개발하는 전문 서비스(미국산업디자인협회 웹사이트)

상호작용 디자인 : 초점은 사람들이 기술과 상호작용하는 방식에 있다. 그 목표는 할 수 있는 일,

진행되는 사건 그리고 이제 발생한 일에 대한 사람들의 이해를 높이는 것이다.

상호작용 디자인은 심리학, 디자인, 예술 및 정서의 원리를 바탕으로 긍정적이고, 즐거운 체험을

보장하고자 한다.

체험 디자인 : 전체 경험의 질과 즐거움에 초점을 두고, 제품, 과정, 서비스, 사건 및 환경을 디자인하는 업무

인간 중심 디자인

HCD와 디자인 명세의 역할

체험 디자인, 산업 디자인, 상호 작용 디자인 : 초점 영역들

인간 중심 디자인 : 디자인이 그것들이 의돟나 사람의 필요와 능력에 들어 맞는지를 확실히 하는 과정

우리가 제품과 상호작용을 할 때, 우리는 그것을 어떻게 작동시킬 것인지를 알아차릴 필요가 있다.

그것이 무엇을 하는지, 어떻게 작동하는지, 어떤 조작이 가능한지를 발견하는 것, 즉 발견 가능성 밀이다.

발견 가능성은 다음 몇장에서 다뤄지는 다섯 개의 기초적인 심리학 개념을 적절히 응용하는 데에서 생긴다.

그것은 행위 지원성, 기표, 제약, 대응 및 피드백 이다.

여섯 번째 원리도 있다. 아마 가장 중요한 것일 텐데, 그것은 시스템에 대한 개념 모형이다.

진정한 이해를 주는 것이 바로 개념 모형이다.

나는 이들 기초 원리를 다룰 것인데, 행위 지원성, 기표, 대응 및 피드백부터 개념 모형으로 넘어갈 것이다.

행위 지원성

행위 지원성이라는 용어는 물리적인 대상과 사람 사이의 관계를 가리킨다. 행위 지원성은 물체의 속성과

행위자의 능력간 속성 관계성으로, 그 물체가 가능하면 어떻게 사용될 수 있을 것인지를 결정한다.

의자는 받침을 제공하고, 그러므로 앉음을 지원한다.

대부분의 의자는 단 한사람의 힘만으로 나를 수 있는데, 그러나 일부 의자들은 힘센 사람이나 몇몇 사람만이

들 수 있다. 어리거나, 비교적 약한 사람이 의자를 들 수 없다면, 이런 사람에게 의자는 행위지원성을 지원하지 않는다.

유리는 투명성을 지원한다.

동시에 그것의 물리구조는 대부분의 물건의 통과를 차단한다.

그 결과 유리는 통과해서 봄과 받침을 지원하지만, 공기나 대부분의 물질의 통과는 지원하지 않는다.

통과의 차단은 반행위 지원성, 즉 상호작용의 금지로 간주될 수 있다. 

효과가 있으려면, 행위지원성과 반행위 지원성은 발견 가능해야, 즉 지각 가능해야 한다.

이것은 유리에게 어려움을 제기한다.

우리가 유리를 좋아하는 이유는 유리가 눈에 잘 보이지 않기 때문이다.

이것은 보통 창에는 유용하지만, 반행위 지원성을 숨긴다면,

날아가던 새가 목숨을 잃을 것이고, 뛰거나 걷던 사람 또한 부딪히고 다칠 것이다.

그것의 출현을 알리는 것을 기표라고 부른다.

기표라는 용어는 기호와 상징의 연구인 기호학이라는 이국적인 분야에서 오래되었으며,

눈에 띄는 내력을 가지고 있다.

그러나 내가 행위지원성을 전용하여 창안자가 의도했던 바와 약간 다른 방식으로

디자인에서 사용하듯이 나는 기표를 기호학에서 사용되는 것과 약간 다른 방식으로 사용한다.

나에게 기표라는 용어는 어떤 표식이나 소리, 즉 적절한 행동을 사람에게 알려주며

자각될 수 있는 어떤 표시기를 가리킨다.

 . . . 중략

[冊] 이펙티브 자바

2장 객체 생성과 파괴 아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라 클래스는 클라이언트에 public 생성자 대신 (혹은 생성자와 함께) 정적 팩터리 메서드를 제공할 수 있다. 이 방식에는 장점과 단점이 모두 존재한다. 먼저 정적 팩터리 메서드가 생성자보다 좋은 장점 다섯 가지를 알아 보자. 첫 번째, 이름을 가질 수 있다. 생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다. 반면 정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다. 예컨대 생성자인 BigInteger(int, int, Random)과 정적 팩터리 메서드인 BigInteger.probablePrime 중 어느 쪽이 ‘값이 소수인 BigInteger를 반환한다’는 의미를 잘 설명할 것 같은지 생각해 보라. (BigInteger.probablePrime은 자바 4에서 추가됐다.) 하나의 시그니처로는 생성자 하나만 만들 수 있다. 입력 매개변수들의 순서를 다르게 한 생성자는 새로 추가하는 식으로 이 제한을 피해볼 수도 있지만, 좋지 않은 발상이다. 그런 API를 사용하는 개발자는 각 생성자가 어떤 역할을 하는지 정확히 기억하기 어려워 엉뚱한 것을 호출하는 실수를 할 수 있다. 코드를 읽는 사람도 클래스 설명 문서를 찾아보지 않고는 의미를 알지 못할 것이다. 이름을 가질 수 있는 정적 팩터리 메서드에는 이런 제약이 없다. 한 클래스에 시그니처가 같은 생성자가 여러 개 필요할 것 같으면, 생성자를 정적 팩터리 메서드로 바꾸고 각각의 차이를 잘 드러내는 이름을 지어주자. 두 번째, 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다. 이 덕분에 불변 클래스는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다. 대표적 예은 Boolean.valueOf(boolean) 메서드는 객체를 아예 생성하지 않는다. 따라서 (특히 생성 비용이 큰) 같은 객체가 자주 요청되는 상황이라면 성능을 상당히 끌어올려 준다. 플라이웨이트 패턴도 이와 비슷한 기법이라 할 수 있다. 반복되는 요청에 같은 객체를 반환하는 식으로 정적 팩터리 방식의 클래스는 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제할 수 있다. 이런 클래스를 인스턴스 통제 클래스하고 한다. 그렇다면 인스턴스를 통제하는 이유는 무엇일까? 인스턴스를 통제하면 클래스를 싱글턴으로 만들 수도, 인스턴스화 불가로 만들수도 있다. 또한 불편 값 클래스에서 동작인 인스턴스가 단 하나뿐임을 보장할 수 있다. 인스턴스 통제는 플라이웨이트 패턴의 근간이 되며, 열거 타입은 인스턴스가 하나만 만들어짐을 보장한다. 세 번째, 반환 타입의 하위 타입을 객체를 반환할 수 있는 능력이 있다. 이 능력은 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 ‘엄청난 유연성’을 선물한다. API를 만들 때 이 유연성을 응용하면 구현 클래스를 공개하지 않고도 그 객체를 봔환할 수 있어 API를 작게 유지할 수 있다. 이는 인터페이스를 정적 팩터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워크를 만드는 핵심 기술이기도 하다. 자바 8 전에는 인터페이스에 정적 메서드를 선언할 수 없었다. 그렇기 때문에 이름이 “Type”인 인터페이슬르 반환하는 정적 메서드가 필요하면, “Types”라는 동반 클래스를 만들어 그 안에 정의한느 것이 관례였다. 예컨대 자바 컬렉션 프레임워크는 핵심 인터페이스들에 수정 불가나 동기화 등의 기능을 덧붙인 총 45개 클래스를 공개하지 않기 때문에 API 외견을 훨씬 작게 만들 수 있었다. API가 작아진 것은 물론 개념적인 무게, 즉 프로그래머가 API를 사용하기 위해 익혀야하는 개념의 수와 난이도를 낮췄다. 프로그래머는 명시한 인터페이스대로 동작하는 객체를 얻을 것임을 알기에 굳이 별도 문서를 찾아가며 실제 구현 클래스가 무엇인지 알아보지 않아도 된다. 나아가 정적 팩터리 메서드를 사용하는 클라이언트는 얻은 객체를 인터페이스만으로 다루게 된다. 이는 일반적으로 좋은 습관이다. 자바 8부터는 인터페이스가 정적 메서드를 가질 수 없다는 제한이 풀렸기 때문에 인스턴스화 불가 동반 클래스를 둘 이유가 별로 없다. 동반 클래스에 두었던 public 정적 멤버들 상당 수를 그냥 인터페이스 자체에 두면 되는 것이다. 하지만 정적 메서드들을 구현하기 위한 코드 중 많은 부분은 여전히 별도의 package-private 클래스에 두어야 할 수 있다. 자바 8에서도 인터페이스에는 public 정적 메서드까지 허락하지만 정적 필드와 정적 멤버 클래스는 여전히 public 이어야 한다. 네 번째, 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다. 반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없다. 심지어 다음 릴리스에서는 또 다른 클래스의 객체를 반환해도 된다. 가령 EnumSet 클래스는 public 생성자 없이 오직 정적 팩터리만 제공하는데, OpenJDK에서는 원소의 수에 따라 두 가지 하위 클래스 중 하나의 인스턴스를 반환한다. (대다수에 해당하는) 원소가 64개 이하면 원소들을 long 변수 하나로 관리하는 RegularEnumSet의 인스턴스를 반환한다. 클라이언트는 이 두 클래스의 존재를 모른다. 만약 원소가 적을 때 RegularEnumSet을 사용할 이점이 없어진다면 다음 릴리스 때는 이를 삭제해도 아무 문제가 없다. 비슷하게, 성능을 더 개선한 세 번째, 네 번째 클래스를 다음 릴리스에 추가할 수도 있다. 클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고 알 필요도 없다. EnumSet의 하위 클래스 이기만 하면 되는 것이다. 다섯 번째, 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다. 이런 유연함은 서비스 제공자 프레임워크를 만드는 근간이 된다. 대표적인 서비스 제공자 프레임워크로는 JDBC가 있다. 서비스 제공자 프레임워크에서의 제공자는 서비스의 구현체이다. 그리고 이 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제하여, 클라이언트를 구현체로부터 분리해준다. 서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 이뤄진다. 구현체의 동작을 정의하는 서비스 인터페이스, 제공자가 구현체를 등록할 때 사용하는 제공자 등록 API, 클라이언트가 서비스의 인스턴스를 얻을 때 사용하는 서비스 접근 API를 사용할 때, 원하는 구현체의 조건을 명시할 수 있다. 조건을 명시하지 않으면 기본 구현체를 반환하거나 지원하는 구현체들을 하나씩 돌아가며 반환한다. 이 서비스 접근 API가 바로 서비스 제공자 프레임워크의 근간이라고 한 ‘유연한 정적 팩터리’의 실체이다. 3개의 핵심 컴포넌트와 더불어 종종 서비스 제공자 인터페이스라는 네 번째 컴포넌트가 쓰이기도 한다. 이 컴포넌트는 서비스 인터페이스의 인스턴스를 생성하는 팩터리 객체를 설명해준다. 서비스 제공자 인터페이스가 없다면 각 구현체를 인스턴스로 만들 때 리플렉션을 사용해야 한다. JDBC에서는 connection이 서비스 인터페이스 역할을, DriverManager, registerDriver가 제공자 등록 API 역활을, DriverManager.getConnection이 서비스 접근 API 역할을, Driver가 서비스 제공자 인터페이스 역할을 수행한다. 서비스 제공자 프레임워크 패턴에는 여러 변형이 있다. 예컨대 서비스 접근 API는 공급자가 제공하는 것보다 더 풍부한 서비스 인터페이스를 클라이언트에 반환할 수 있다. 브리지 패턴이라 알려진 것이다. 의존 객체 주입 프레임워크도 강력한 서비스 제공자라고 생각할 수 있다. 자바 5부터는 java.util.ServiceLoader라는 범용 서빗 제공자 프레임워크가 제공되어 프레임워크를 직접 만들 필요가 거의 없어졌다. 한편, JDBC는 자바 5 전에 등장한 개념이라 ServiceLoader를 사용하지 않는다.

REACT,문제 풀기

REACT,답

REACT,문제

JAVASCRIPT,답

JAVASCRIPT,문제

JAVASCRIPT,문제 풀기

JAVA답

JAVA 문제

JAVA 문제 풀기

SQLD

Computer Science 이론

 Computer Science 이론

Algorithm 문제풀기

 Algorithm 문제풀기

Algorithm 답

 Algorithm 답

Algorithm 문제

 Algorithm 문제

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

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

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

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

(대략 문제 제기)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

할 수 있다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 - 안전한 탐색

 - 즉각적 만족

 - 만족화

 - 중도에 바꾸기

 - 선택 미루기

 - 점진적 창조

 - 습관화

- 짬 시간 활용

 - 공간 기억

 - 미래 계획 기억

 - 능률적 반복

 - 키워드만 사용하기

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

 - 안전한 탐색

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

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

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

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

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

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

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

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

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

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

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

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

 - 즉각적 만족

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

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

이는 인간의 본성이다.

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

얼마나 만족스럽겠는가!

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

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

 - 만족화

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

 - 중도에 바꾸기

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

 - 선택 미루기

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

 - 점진적 창조

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

 - 습관화

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

- 짬 시간 활용

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

 - 공간 기억

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

 - 미래 계획 기억

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

 - 능률적 반복

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

 - 키워드만 사용하기

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

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

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

[冊] 리팩터링

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

리팩터링 정의

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

내부 구조를 변경하는 기법

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

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 사용한다.

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

[冊] 사용자를 끌어들이는 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잡러 시대의 슬기로운 직장 생활

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

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

[冊] 리팩터링 : 목차

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분의 힘

Rule Update 2021-10-14

문제 의식(問題意識) 

1. 기존 컴퓨터 지식 관련 블로그는 A-Z까지 사사롭게 기술되어 있다. 때문에 제 3자가 내용을 알아보기 힘들다.
2. 때때로 Senior Developer님이 보시기에 내가 공부한 학습량에 대해서 잘 인정받지 못한다.
3. 간단한 내용을 기억하지 못한다.
4.  대답할 때 명료하게 정리해서 말하지 못한다.
5.  시간이 지나면 기존에 했던 것을 자꾸 잊어버린다.
6.  말로 전달하기까지 기억하는데 시간이 오래 걸린다.
7.  구글 검색에 너무 의존한다.
8.  해당 지식에 대해서 두루뭉술하게 기억하고 있다.
9.  기술 면접 위주의 CS 질문들을 해결하고 싶다.
10. 외국어 소통에 대한 중요성과 신기술 혹은 해외 개발자들이 기술한 영어 문서를 읽기 위한 노력이 필요하다.

해결 방법

1. 암기하는 방법에 대해서도 정리를 해둔다.
2. 단기간 내에 정리된 학습 내용을 반복하여 암기한다.
3. 키워드 위주로 암기한다.
4. 일본어는 한자어가 익숙해지기 위해 한글 옆에 같이 기술한다.
5. 위와 같은 방법으로 영어 패턴, 일본어 패턴도 같이 정리하여 바로 대응할 수 있을 정도로 암기를 반복한다.
6. 새롭게 알게 된 지식, 잘못 알았던 지식들에 대한 기술은 업데이트한다.

기술 블로그를 기술하는 목적

1. 제 3자가 알아볼 수 있는 기술 블로그의 필요성을 느꼈다.
2. 기초 기반 위주의 지식들을 먼저 정리한다.
3. 해당 지식들에 대하여 간단하게 소스 코드를 가지고 설명할 수 있어야 한다.
4. 재 사용 가능한 코드를 작성하여야 한다.
5. 더 나은 코드의 방향성을 제시할 수 있어야 한다.
6. 기술 블로그를 기술하는데, 시간이 많이 소요되더라도 말과 그림으로 논리정연하게 설명할 수 있어야 한다.

기술 블로그 작성 요령

1. 먼저 Rough하게 작성한 다음에,
2. 추가되어야 하거나, 빠져야 하는 내용 또한 다듬을 것이고,
3. 그 전에는 맞는 말이였을지라도 바뀐 내용이 있다면 재명시할 것이다.
    
4. 그리고 이전에 기술했던 내용이라도 제 스스로 부족함을
5. 느낀다면 몇 번이고 백지상태에서 다시 반복할 것이다.
6. 사람은 일주일이면 망각의 강을 건너기 시작하기 때문이다..

ff

aa

jQuery

1. 1 jQuery Basics
2. 2 jQuery Ajax & JSON
3. 3 jQuery Deferred Object
4. 4 jQuery Plugin

JavaScript

 

1. 1 기본 개념과 동작 원리 이해의 중요성
2. 2 자바스크립트란?
3. 3 자바스크립트 개발 환경과 실행 방법
4. 4 브라우저 동작 원리
5. 5 자바스크립트의 기본 문법
6. 6 데이터 타입과 변수
7. 7 연산자
8. 8 제어문
9. 9 타입 변환과 단축 평가
10. 10 객체
11. 11 객체와 변경불가성(Immutability)
12. 12 함수
13. 13 타입 체크
14. 14 프로토타입
15. 15 스코프
16. 16 보다 안정적인 자바스크립트 개발 환경을 위한 Strict mode
17. 17 함수 호출 방식에 의해 결정되는 this
18. 18 실행 컨텍스트와 자바스크립트의 동작 원리
19. 19 클로저
20. 20 자바스크립트 객체지향 프로그래밍
21. 21 빌트인 객체
22. 22 전역 객체
23. 23 Number 레퍼 객체
24. 24 수학 상수와 함수를 위한 Math 객체
25. 25 날짜와 시간을 위한 Date 객체
26. 26 정규표현식
27. 27 String 레퍼 객체
28. 28 배열
29. 29 자바스크립트 배열은 배열이 아니다
30. 30 배열 고차 함수
31. 31 문서 객체 모델(Document Object Model)
32. 32 동기식 처리 모델 vs 비동기식 처리 모델
33. 33 이벤트
34. 34 디바이스의 방향 정보를 다루는 자바스크립트 이벤트
35. 35 비동기식 처리 모델과 Ajax
36. 36 REST(Representational State Transfer) API
37. 37 Single Page Application & Routing

CSS3

 

1. 1 CSS 기본 문법
2. 2 셀렉터
3. 3 CSS 프로퍼티 값의 단위
4. 4 박스 모델
5. 5 display, visibility, opacity 프로퍼티
6. 6 백그라운드
7. 7 폰트와 텍스트
8. 8 요소의 위치 정의
9. 9 요소 정렬
10. 10 스타일의 상속과 적용 우선 순위
11. 11 벤더 프리픽스
12. 12 그림자
13. 13 그레이디언트
14. 14 트랜지션
15. 15 애니메이션
16. 16 트랜스폼
17. 17 웹디자인 타이포그래피(Typography)
18. 18 레이아웃
19. 19 반응형 레이아웃
20. 20 플렉스 박스 레이아웃
21. 21 수평/수직 중앙 정렬
22. 22 image 요소 아래에 패딩된 여분의 공간 제거하기

HTML5

 

1. 1 프런트엔드 개발자 학습 방향
2. 2 HTML5 기본 문법
3. 3 시맨틱 요소와 검색 엔진
4. 4 웹페이지의 구성하는 기본 태그
5. 5 텍스트 관련 태그
6. 6 HTML의 핵심 개념인 Hyperlink
7. 7 목록(List)와 표(Table) 형식 표현을 위한 태그
8. 8 이미지의 표현과 동영상, 음악 등 멀티미디어를 지원하는 태그
9. 9 사용자와의 커뮤니케이션을 위한 폼 태그
10. 10 웹페이지의 레이아웃을 구성하기 위해 공간을 분할하는 태그