Not found
This page doesn’t exist (yet?)
diff --git a/404.html b/404.html index 0a4eec8..ea9aa1c 100644 --- a/404.html +++ b/404.html @@ -1 +1 @@ -
This page doesn’t exist (yet?)
This page doesn’t exist (yet?)
《루비로 배우는 객체지향 디자인》의 9장 ‘비용-효율적인 테스트 디자인하기’ 파트를 읽고 정리한 내용입니다.
+《루비로 배우는 객체지향 디자인》의 9장 ‘비용-효율적인 테스트 디자인하기’ 파트를 읽고 정리한 내용입니다.
테스트 중인 객체의 가장자리를 따라 시선을 고정하고, 그 경계를 넘나드는 메시지만 테스트하는 것이 좋다. (내부나 작동 방식에 집중하면 프라이빗한 지식이 테스트를 침범하고, 결합이 강해진다.)
테스트는 꼭 필요하다. 잘 디자인된 애플리케이션은 매우 추상적이고, 계속 변경된다. 테스트가 없다면 이해할 수도 없고 안전하게 수정할 수도 없을 것이다. 최상의 테스트는 실제 코드와 느슨하게 결합되어야 한다. 그리고 모든 코드를 한번만, 제대로 된 장소에서 테스트해야 한다. 이런 테스트는 코드 작성 비용을 높이지 않으면서도 새로운 가치를 제공한다.
-잘 디자인된 애플리케이션이 섬세하게 다듬어진 테스트 묶음을 가지고 있다면 이 애플리케이션을 바라보기만 해도 기쁘고 확장하는 작업도 즐겁다. 모든 새로운 상황에 적응할 수 있으며 예상치 못했던 그 어떤 요구사항에도 대처할 수 있다.
잘 디자인된 애플리케이션이 섬세하게 다듬어진 테스트 묶음을 가지고 있다면 이 애플리케이션을 바라보기만 해도 기쁘고 확장하는 작업도 즐겁다. 모든 새로운 상황에 적응할 수 있으며 예상치 못했던 그 어떤 요구사항에도 대처할 수 있다.
Deep dive: How do React hooks really work?을 저자, Swyx의 허락을 받고 번역한 글입니다. 오타, 오역은 제보해주시면 수정하도록 하겠습니다.👍🏻
+Deep dive: How do React hooks really work?을 저자, Swyx의 허락을 받고 번역한 글입니다. 오타, 오역은 제보해주시면 수정하도록 하겠습니다.👍🏻
클로저는 함수와 그 함수가 선언됐을 때의 렉시컬 환경(Lexical environment)의 조합이다. - MDN
또한 두 번째 규칙인 “오직 React 함수 내에서 Hook을 호출해야 합니다.”는 우리가 구현한 코드에서는 필수적이지 않지만, 항상 코드의 어떤 부분이 상태 관련 로직에 의존하는지 명확하게 구분하는 것은 좋은 습관입니다. (긍정적인 부수효과로, 반복문과 조건문 내부에서 일반 JavaScript 함수처럼 이름 붙여진 상태 관련 함수를 호출하는 실수를 하지 않게 됩니다. 즉, 두 번째 규칙을 따르는 것이 첫 번째 규칙을 따르는 데 도움이 됩니다.)
여기까지 이 글에서 학습해볼 내용은 다 다루었습니다. 이제 useRef를 한 줄로 구현해보거나 render 함수가 JSX를 받아 실제로 DOM에 마운트 하도록 해보거나 우리가 구현한 28줄의 React Hooks 복제본에서는 생략한 무수히 많은 세부 사항을 추가해볼 수도 있습니다. 아무쪼록 컨텍스트에서 클로저를 사용하는 경험과 React Hook이 동작하는 방식을 이해하는 유용한 멘탈 모델을 얻으셨기를 바랍니다.
-이 글의 초안을 검토하고 값진 피드백으로 개선해 준 Dan Abramov와 Divya Sasidharan에게 감사의 말을 전합니다. 오류가 남아있다면 그건 제 탓입니다..
이 글의 초안을 검토하고 값진 피드백으로 개선해 준 Dan Abramov와 Divya Sasidharan에게 감사의 말을 전합니다. 오류가 남아있다면 그건 제 탓입니다..
《코어 자바스크립트》의 ‘실행 컨텍스트’ 파트를 읽고 정리한 내용입니다.
+《코어 자바스크립트》의 ‘실행 컨텍스트’ 파트를 읽고 정리한 내용입니다.
실행할 코드에 제공할 환경 정보들을 모아놓은 객체이다. JavaScript 엔진은 컨텍스트를 구성하여 이를 call stack에 쌓아 올렸다가, 가장 위에 쌓여 있는 컨텍스트와 관련 있는 코드들을 실행하는 식으로 전체 코드의 환경과 순서를 보장한다.
JSConf Korea 2019의 “How TypeScript Can Power Design System” 발표를 보고 정리한 내용입니다.
+JSConf Korea 2019의 “How TypeScript Can Power Design System” 발표를 보고 정리한 내용입니다.
Isha Kasliwal은 Twitch의 Design System 팀에 시니어 UI/UX Designer/Developer입니다. 이전에는 Salesforce의 Lightning Design System 팀에서 일했다고 합니다.
@@ -209,4 +209,4 @@강력한 타이핑을 통해 발생 가능한 버그를 사전에 줄이고, 프로젝트 관리 및 비즈니스 측면에 집중할 수 있습니다. 물론 버그가 적으니 사용성도 좋아질 것입니다.
‘형태(form)는 기능(function)을 따른다.‘는 말이 있습니다. 코드 작성에 적용해 보면 구조의 형태, 더 나아가 사용하기로 선택한 도구와 그것을 사용하는 방법 등은 기능에 의해 결정된다는 것 입니다. 웹 개발과 관련하여 우리가 하는 모든 작업의 목적은 보다 유용하고 안전한 웹 사이트, 앱을 만드는 것입니다. 개발자와 디자이너로써 우리가 만드는 모든 것의 의도는 사용자에게 미치는 영향을 따라야 합니다. 새로운 라이브러리, 프레임워크를 사용하는 것은 멋진 일이지만, 사용자 그리고 유지보수 할 동료에게 어떠한 긍정적인 영향을 줄 수 있는지 고려하는 것이 중요합니다. 프레임워크를 만드는 사람이라면, 안전과 유용성을 늘 염두 해야 합니다. 사용자가 구축하고 세상에 내놓는 소프트웨어의 의도는 생각보다 큰 영향을 끼칩니다. 따라서 모든 사람의 안전과 신뢰를 고려하는 도구를 사용하는 것이 중요합니다.
‘형태(form)는 기능(function)을 따른다.‘는 말이 있습니다. 코드 작성에 적용해 보면 구조의 형태, 더 나아가 사용하기로 선택한 도구와 그것을 사용하는 방법 등은 기능에 의해 결정된다는 것 입니다. 웹 개발과 관련하여 우리가 하는 모든 작업의 목적은 보다 유용하고 안전한 웹 사이트, 앱을 만드는 것입니다. 개발자와 디자이너로써 우리가 만드는 모든 것의 의도는 사용자에게 미치는 영향을 따라야 합니다. 새로운 라이브러리, 프레임워크를 사용하는 것은 멋진 일이지만, 사용자 그리고 유지보수 할 동료에게 어떠한 긍정적인 영향을 줄 수 있는지 고려하는 것이 중요합니다. 프레임워크를 만드는 사람이라면, 안전과 유용성을 늘 염두 해야 합니다. 사용자가 구축하고 세상에 내놓는 소프트웨어의 의도는 생각보다 큰 영향을 끼칩니다. 따라서 모든 사람의 안전과 신뢰를 고려하는 도구를 사용하는 것이 중요합니다.
ChatGPT Prompt Engineering for Developers 강의 노트
테스트의 진정한 목표는 코드 작성 비용을 줄이는 것이다. 왜, 무엇을, 언제, 그리고 어떻게 테스트 해야할까?
좋은 시스템은 단순하다. ‘단순하다’라는 것은 무엇일까?
하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
React Hook에 대해 이해하려면 JavaScript 클로저에 대해 잘 알아야합니다. React의 작은 복제본을 만들어보며 클로저와 hook의 동작 방식을 알아봅니다.
디자인 시스템에 TypeScript를 적용하여 인터페이스 지향 개발, 정적 코드 분석을 통한 문서 자동화 등의 이점을 얻어보자
객체지향의 세계에서 기능은 객체들 간의 상호 작용들 통해 구현된다. 그리고 그 상호작용은 객체 사이에 주고 받는 메시지로 표현된다.
실행 컨텍스트(Execution Context)란 실행할 코드에 제공할 환경 정보들을 모아놓은 객체이다.
React는 어떻게 동작할까? 왜 그렇게 동작할까? 얼핏 들었던 내부 개념들에 대한 정리
느린 렌더링을 먼저 수정하고, 여전히 필요하다면 불필요한 re-render를 처리
객체지향의 세계에서 기능은 객체들 간의 상호 작용들 통해 구현된다. 그리고 그 상호작용은 객체 사이에 주고 받는 메시지로 표현된다.
ChatGPT Prompt Engineering for Developers 강의 노트
테스트의 진정한 목표는 코드 작성 비용을 줄이는 것이다. 왜, 무엇을, 언제, 그리고 어떻게 테스트 해야할까?
좋은 시스템은 단순하다. ‘단순하다’라는 것은 무엇일까?
하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
React Hook에 대해 이해하려면 JavaScript 클로저에 대해 잘 알아야합니다. React의 작은 복제본을 만들어보며 클로저와 hook의 동작 방식을 알아봅니다.
디자인 시스템에 TypeScript를 적용하여 인터페이스 지향 개발, 정적 코드 분석을 통한 문서 자동화 등의 이점을 얻어보자
객체지향의 세계에서 기능은 객체들 간의 상호 작용들 통해 구현된다. 그리고 그 상호작용은 객체 사이에 주고 받는 메시지로 표현된다.
실행 컨텍스트(Execution Context)란 실행할 코드에 제공할 환경 정보들을 모아놓은 객체이다.
React는 어떻게 동작할까? 왜 그렇게 동작할까? 얼핏 들었던 내부 개념들에 대한 정리
느린 렌더링을 먼저 수정하고, 여전히 필요하다면 불필요한 re-render를 처리
객체지향의 세계에서 기능은 객체들 간의 상호 작용들 통해 구현된다. 그리고 그 상호작용은 객체 사이에 주고 받는 메시지로 표현된다.
Kent C. Dodds의 Fix the slow render before you fix the re-render를 읽으면서 정리한 내용입니다.
+Kent C. Dodds의 Fix the slow render before you fix the re-render를 읽으면서 정리한 내용입니다.
React가 처음 나왔을 때 가장 주목받은 부분은 기존 UI 라이브러리와 구분되는 “Virtual DOM”을 통한 성능 개선이었습니다.
기존DOM을 여러번 업데이트하는 방식 (element.appendChild(childElement)
호출 등)은 여러번 업데이트 하게 되면서 성능 문제가 가중됩니다.
브라우저의 profililing tools ⇒ start profiling ⇒ 인터랙션을 하고 ⇒ stop profiling (예제 보기)
어느 부분 (또는 의존성)이 가장 오래 걸리는 지 파악하고, 문제를 해결 한 후 프로파일러로 개선 되었는지 관찰하세요. 그리고 React DevTools profiler도 굉장히 훌륭하니 참고하세요!
렌더링이 반드시 필요한지 여부는 중요하지 않습니다. 렌더링이 느리면 결국 사용자에게 나쁜 경험을 제공합니다. 깜빡일 때마다 스스로 얼굴을 때리지 마세요. 느린 렌더링을 먼저 수정하세요. 그런 다음 (여전히 필요하다면) “불필요한 re-render”을 처리하세요.
렌더링이 반드시 필요한지 여부는 중요하지 않습니다. 렌더링이 느리면 결국 사용자에게 나쁜 경험을 제공합니다. 깜빡일 때마다 스스로 얼굴을 때리지 마세요. 느린 렌더링을 먼저 수정하세요. 그런 다음 (여전히 필요하다면) “불필요한 re-render”을 처리하세요.
《실용주의 프로그래머》 2장 ‘실용주의 접근법’의 ‘직교성’ 파트를 읽고 정리한 내용입니다.
+《실용주의 프로그래머》 2장 ‘실용주의 접근법’의 ‘직교성’ 파트를 읽고 정리한 내용입니다.
직교성의 개념은 우리가 배우는 여러 다른 방법론과 기법에 잠재되어 있다. 직교성의 원칙을 적용하는 걸 직접 배우게 되면 우리가 만드는 시스템의 질을 즉각 개선할 수 있다.
직교성은 DRY 원리와도 밀접한 관계가 있다. DRY 원리는 시스템 내부의 중복을 최소화시키고, 직교성은 시스템 컴포넌트 간의 상호의존도를 줄인다. DRY 원리로 무장하고 직교성 원리를 충실히 사용한다면 개발하고 있는 시스템이 더 유연하고, 이해하기 쉽고 또한 디버그, 테스트, 유지도 쉬워질 것이다.
-만약 무언가 하나를 변경하기 위해 많은 일을 하는 혹은 하나를 변경할 때마다 다른 네 개의 무언가가 이상해진다면 그 프로젝트는 아마도 직교적으로 설계되거나 코딩되지 않았을 것이다. (리팩터링을 할 시간이다.)
만약 무언가 하나를 변경하기 위해 많은 일을 하는 혹은 하나를 변경할 때마다 다른 네 개의 무언가가 이상해진다면 그 프로젝트는 아마도 직교적으로 설계되거나 코딩되지 않았을 것이다. (리팩터링을 할 시간이다.)
ChatGPT Prompt Engineering for Developers 강의를 들으면서 정리한 내용입니다. 강의에서는 Python을 사용하는데 저는 익숙한 TypeScript, Node.js로 예제 코드를 따라하면서 들었습니다. 제가 작성한 전체 예제 코드는 이 GitHub repo에서 보실 수 있습니다.
+ChatGPT Prompt Engineering for Developers 강의를 들으면서 정리한 내용입니다. 강의에서는 Python을 사용하는데 저는 익숙한 TypeScript, Node.js로 예제 코드를 따라하면서 들었습니다. 제가 작성한 전체 예제 코드는 이 GitHub repo에서 보실 수 있습니다.
단방향 데이터 흐름, 상위 컴포넌트의 상태 변경에 따른 리렌더링, immutable한 state 관리 등 React를 사용하여 개발 하다보면 다른 UI 프로그래밍 모델에서는 낯선 개념들을 마주할 때가 있습니다. Dan Abramov가 이러한 개념들에 대해 명쾌하게 설명한 글 React as a UI Runtime 을 읽으며 간략하게 정리한 내용입니다. 원글의 양이 길어 hooks 등의 개념은 따로 정리할 예정입니다.
+단방향 데이터 흐름, 상위 컴포넌트의 상태 변경에 따른 리렌더링, immutable한 state 관리 등 React를 사용하여 개발 하다보면 다른 UI 프로그래밍 모델에서는 낯선 개념들을 마주할 때가 있습니다. Dan Abramov가 이러한 개념들에 대해 명쾌하게 설명한 글 React as a UI Runtime 을 읽으며 간략하게 정리한 내용입니다. 원글의 양이 길어 hooks 등의 개념은 따로 정리할 예정입니다.
React는 일반적으로 동적으로 변화할 수 있는 트리를 출력하는 프로그램이다. (DOM 트리, PDF 요소들의 트리, JSON 객체 등) 이것을 ‘호스트 트리’ 라고 한다. (DOM이나 iOS와 같이 외부 호스트 환경의 일부이기 때문)
React는 외부 상호작용, 네트워크 응답, 타이머 등 외부 이벤트에 대한 응답으로 복잡한 호스트 트리를 예측할 수 있게 조작하는 프로그램을 작성하는데 유용하다.
@@ -204,4 +204,4 @@React는 내부적으로 현재 렌더되어 있는 컴포넌트를 기억하기 위해 자체적인 호출 스택이 있다. (e.g. 가령 [App, Page, Layout, Article /** 현재 렌더링 하는 부분 **/])
이 트리들은 상호작용하기 위해서 계속 살아 있어야 한다. 즉 Article 컴포넌트의 렌더가 끝나도 React 호출 트리는 파괴되지 않는다. local state와 호스트 인스턴스의 참조를 어딘가에 유지해야 한다.
호출 트리 프레임은 재조정 규칙에 따라 지역 상태, 호스트 인스턴스와 함께 파괴됩니다. React 소스를 읽어봤다면 이러한 프레임을 파이버라고 부르는 것을 볼 수 있다.
-파이버는 지역 상태가 실제로 있는 곳이다. 지역 상태가 업데이트될 때 React는 해당 파이버의 자식들을 재조정하고 해당 컴포넌트들을 호출한다.
파이버는 지역 상태가 실제로 있는 곳이다. 지역 상태가 업데이트될 때 React는 해당 파이버의 자식들을 재조정하고 해당 컴포넌트들을 호출한다.
《오브젝트: 코드로 이해하는 객체지향 설계》의 ‘역할, 책임, 협력’ 파트를 읽고 정리한 내용입니다.
+《오브젝트: 코드로 이해하는 객체지향 설계》의 ‘역할, 책임, 협력’ 파트를 읽고 정리한 내용입니다.
객체 지향 프로그래밍을 이해하기 위해 가장 중요한 것은 무엇일까? 클래스, 상속, 지연 바인딩 등 일까? 이러한 것들은 다분히 구현 측면에 치우쳐 있기 때문에 객체지향 패러다임의 본질과는 거리가 멀다.
역할의 구현하는 가장 일반적인 방법은 추상클래스와 인터페이스를 사용하는 것이다. 추상 클래스는 책임의 일부를 구현해놓은 것이고 인터페이스는 일체의 구현 없이 책임의 집합만을 나열해 놓았다는 차이가 있다.
여러 종류의 객체에 의해 수행될 필요가 있다면 ⇒ 역할, 한 종류의 객체만이 협력에 참여할 필요가 있다면 ⇒ 객체
-대부분의 경우에 어떤 것이 역할이고 어떤 것이 객체인지가 또렷하게 드러나지는 않을 것이다. 설계 초반에는 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요한 목표여야 하고 역할과 객체를 명확하게 구분하는 것은 그렇게 중요하지 않다. ⇒ 객체로 시작하고 필요한 순간에 객체로부터 역할을 분리
대부분의 경우에 어떤 것이 역할이고 어떤 것이 객체인지가 또렷하게 드러나지는 않을 것이다. 설계 초반에는 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요한 목표여야 하고 역할과 객체를 명확하게 구분하는 것은 그렇게 중요하지 않다. ⇒ 객체로 시작하고 필요한 순간에 객체로부터 역할을 분리
아래 두 자료를 보면서 정리한 글입니다. 먼저 번역해주신 분들 덕분에 비원어민인 저도 이 자료를 접할 수 있었습니다. 훌륭한 지식을 쉽게 접할 수 있도록 앞서 기여해주신 번역자분들에게 감사드립니다.
+아래 두 자료를 보면서 정리한 글입니다. 먼저 번역해주신 분들 덕분에 비원어민인 저도 이 자료를 접할 수 있었습니다. 훌륭한 지식을 쉽게 접할 수 있도록 앞서 기여해주신 번역자분들에게 감사드립니다.
《오브젝트: 코드로 이해하는 객체지향 설계》의 ‘객체, 설계’ 파트를 읽고 정리한 내용입니다.
+《오브젝트: 코드로 이해하는 객체지향 설계》의 ‘객체, 설계’ 파트를 읽고 정리한 내용입니다.
어떤 분야를 막론하고, 이론을 정립할 수 없는 초기에는 실무가 먼저 급속한 발전을 이룬다. (…) 해당 분야가 충분히 성숙해지는 시점에 이르러서야 이론이 실무를 추월하게 된다. - Rober L. Glass (소프트웨어 크리에이비티 2.0 中)
@@ -146,4 +146,4 @@객체지향 설계
우리가 진정으로 원하는 것? 변경에 유연하게 대응할 수 있는 코드. 객체지향 패러다임은 세상을 바라보는 방식대로 코드를 작성할 수 있게 돕는다. 데이터와 프로세스를 객체 안으로 밀어 넣었다고 변경하기 쉬운 설계를 얻을 수 있는 것은 아님. 객체지향의 세계에서 애플리케이션은 객체들로 구성되며 애플리케이션의 기능은 객체들 간의 상호 작용들 통해 구현된다. 그리고 객체들 사이의 상호작용은 객체 사이에 주고 받는 메시지로 표현된다.
-⇒ 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계👏🏻
⇒ 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계👏🏻