전체 글

전체 글

    [패캠] The RED : 김민태의 React와 Redux로 구현하는 아키텍처와 리스크 관리

    오늘은 패스트캠퍼스에서 최근에 수강했던 김민태님의 강의를 듣고 학습했던 내용을 정리해 보려고 한다. 시작하기에 앞서서 이 강의는 패캠에서 어떠한 대가도 제공받지 않고 직접 수강하고 내용을 정리하는 것임을 밝힌다. 목차 1. 프론트엔드 개발자가 갖춰야 할 필수 소프트 스킬 한 회사에 종속된 기술을 사용하는 것은 위험하다. e.g. Flash 개발자가 개발만 잘 한다고 좋은 제품이 나오는 것은 아니구나. e.g. 모바일 서비스 어떻게 하면 기술을 쉽게 이해할 수 있을까? e.g. 외계어 스터디 WEB 개방형 스탠다드 웹을 제외하고는 벤더 디펜던시가 있다(iOS, Android, Java-Spring 등) 웹도 지금 100% 개방형 기술이라고 보기는 어렵다. FRONT 제일 앞에 있다. 시각적 요소 중요 EN..

    [알고리즘 문제 해결 전략] Ch03-2. 알고리즘 설계 패러다임 (분할 정복)

    7 분할 정복 7.1 분할 정복 분할 정복(Divide & Conquer)은 가장 유명한 알고리즘 디자인 패러다임으로, 각개 격파라는 말로 간단히 설명할 수 있다. 분할 정복 패러다임을 차용한 알고리즘들은 주어진 문제를 둘 이상의 부분 문제로 나눈 뒤 각 문제에 대한 답을 재귀 호출을 이용해 계산하고, 각 부분 문제의 답으로부터 전체 문제의 답을 계산해 낸다. 분할 정복이 일반적인 재귀 호출과 다른 점은 문제를 한 조각과 나머지 전체로 나누는 대신 거의 같은 크기의 부분 문제로 나누는 것이다. 이 차이점이 아래 그림이다. 그림 (a)는 항상 문제를 한 조각과 나머지로 쪼개는 일반적인 재귀 호출 알고리즘을 보여주고, 그림 (b)는 항상 문제를 절반씩으로 나누는 분할 정복 알고리즘을 보여준다. 분할 정복을 ..

    [Ringle] 튜터 피드백 정리 (October 2021)

    링글을 벌써 8개월째 계속 하고 있다. 월 평균 4~6회 정도 수업을 받고 있으니 지금까지 총 40회 정도 수업을 했었던 것 같다. 수업을 받고 튜터님들이 피드백을 해 주시는데, 중복되는 피드백도 많고 그 말은 즉슨 내가 자주 하는 실수라는 의미이므로 이러한 것들을 정리해 보면 좋을 것 같다는 생각이 들었다. 더 까먹기 전에 내가 받았던 피드백들을 정리해 보려고 한다. October/01/2021 (7.5) The more proper style for me is audio style -> the most effective way for me to learn is through audio Other countries where speak in English -> Other countries English..

    [알고리즘 문제 해결 전략] Ch03-1. 알고리즘 설계 패러다임 (브루트 포스)

    06 무식하게 풀기 6.1 도입 흔히 전산학에서 무식하게 푼다(brute-force)는 말은 컴퓨터의 빠른 계산 능력을 이용해 가능한 경우의 수를 일일이 나열하면서 답을 찾는 방법을 의미한다. 이렇게 가능한 방법을 전부 만들어 보는 알고리즘들을 가리켜 흔히 완전탐색(exhaustive search)이라고 부른다. 얼핏 보면 이런 것을 언급할 가치가 있나 싶을 정도로 간단한 방법이지만, 완전탐색은 사실 컴퓨터의 장점을 가장 잘 이용하는 방법이다. 컴퓨터의 최대 장점은 속도가 빠르다는 것이기 때문이다. 6.2 재귀 호출과 완전 탐색 재귀 호출 재귀 함수란 자신이 수행할 작업을 유사한 형태의 여러 조각으로 쪼갠 뒤 그 중 한 조각을 수행하고, 나머지를 자기 자신을 호출해 실행하는 함수를 가리킨다. 예를 들면 ..

    [소프트웨어 아키텍처 101] Ch03. 모듈성

    플랫폼마다 제공하는 코드 재사용 메커니즘은 제각각이지만, 연관된 코드를 모듈(module)로 묶는 방법은 모두 지원한다. 본인이 선택한 개발 플랫폼에서 모듈성과 그것을 구현한 수 많은 코드를 이해하는 것은 아키텍트에게 대단히 중요한 일이다. 우리가 아키텍처를 분석해야 할 (메트릭, 피트니스 함수, 시각화 등) 많은 도구가 이 모듈성에 기반하기 때문이다. 모듈성은 일종의 구성 원리(organizing principle)이다. 아키텍트가 대충 아무렇게나 조각들을 이어 붙여 시스템을 설계하면 무수한 난관에 봉착해 옴짝달싹 못 하는 시스템이 되어 버린다. 물리학에 비유 하자면, 소프트웨어 시스템은 엔트로피(entropy, 무질서)가 증가하는 방향으로 움직이는 복잡한 시스템을 모델링한다. 질서를 유지하려면 물리적..

    [이펙티브 타입스크립트] 3장 타입 추론

    타입스크립트는 타입 추론을 적극적으로 수행한다. 타입 추론은 수동으로 명시해야 하는 타입 구문의 수를 엄청나게 줄여 주기 때문에, 코드의 전체적인 안정성이 향상된다. 숙련된 타입스크립트 개발자는 비교적 적은 수의 구문을 사용한다. 반면, 초보자의 코드는 불필요한 타입 구문으로 도배되어 있다. 이번 장을 읽고 나면 타입스크립트가 어떻게 타입을 추론하는지, 언제 타입 선언을 해야 하는지, 타입 추론이 가능하더라도 명시적으로 타입 선언을 작성하는 것이 필요한 상황은 언제인지 잘 이해할 수 있다. 아이템 19. 추론 가능한 타입을 사용해 장황한 코드 방지하기 타입 추론이 된다면 명시적 타입 구문은 필요하지 않다. 오히려 방해가 될 뿐이다. let x: number = 12; // 굳이? let x = 12; /..

    [알고리즘 문제 해결 전략] Ch02. 알고리즘 분석

    02 알고리즘 분석 (04 ~ 05) 04 알고리즘 시간 복잡도 분석 4.1 도입 두 알고리즘의 속도를 비교하는 가장 직관적인 방법은 각각을 프로그램으로 구현한 뒤 같은 입력에 대해 두 프로그램의 수행 시간을 측정하는 것이다. 하지만 프로그램의 실행 시간은 알고리즘의 속도를 일반적으로 이야기하는 기준이 되기에는 부적합하다. 가장 큰 이유는 프로그램의 수행 시간은 사용한 프로그래밍 언어, 하드웨어는 물론이고 운영체제, 컴파일러까지 수 많은 요소에 의해 바뀔 수 있기 때문이다. 두 번째 이유는 실제 수행 시간이 다양한 입력에 대한 실행 시간을 반영하지 못하기 때문이다. 알고리즘의 수행 시간을 지배하는 것은 반복문이다. 입력의 크기가 작을 때는 반복외의 다른 부분들이 갖는 비중이 클 수가 있지만, 입력의 크기..

    [소프트웨어 아키텍처 101] Ch02. 아키텍처 사고

    아키텍처의 사고는 크게 네 가지로 나뉜다. 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하면 개발팀과 어떻게 협력해야 할지 아는 것 어느 정도 기술의 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것 아키텍트는 다른 사람들이 보지 못하는 해결책과 가능성을 떠올릴 수 있다. 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고 조율하는 것 비즈니스 동인(business driver)의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것 2.1 아키텍처 대 설계 아키텍트처럼 사고한다는 건 비즈니스와 기술 문제를 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것이다. 전통적인 아키텍트의 책임과 개발자의 책임은 다음과 같다. 이 전통적인 아키..