코드를 위한 기록

조건을 설정하여 를 나타낼 지 결정할 수 있음 return문 안에서 삼항연산자 조건 ? 참일 때 실행 : 아닐 때 실행 &&연산자 조건 && 참일 때 실행 -> false일 때는 실행하지 않음(컴포넌트를 렌더링하지 않음) -> falsy값을 리턴하면 falsy값을 나타냄 → 조건이 너무 길다면 컴포넌트로 분리할 것 컴포넌트 안에서 컴포넌트 내에서 렌더링하지 않도록 조건 넣기 null if (조건) { return null } return ... // false일 경우 실행할 엘리먼트 22.12.11

MERN stack : JS 프레임워크 MongoDB, Express, React, Node.js를 지칭 Node.js HTTP 모듈과 비교하면 Express는 라우터를 제공하며 미들웨어를 추가할 수 있음 Express 설치 // 터미널 npm install express const express = require('express') const app = express() // express의 인스턴스 const port = 3000 // app.메서드(경로, 핸들러) 형식으로 사용 app.get('/', (req, res) => { res.send('Hello World') }) app.listen(port, () => { console.log('연결되었습니다') }) 라우팅 : 클라이언트의 요청에 해..

기본적으로 SOP를 따라 다른 출처 리소스를 제한하지만, CORS를 사용해 접근 권한을 얻을 수 있음 SOP(Same-Origin Policy, 동일 출처 정책) : 모든 브라우저가 기본적으로 적용 중 같은 출처(프로토콜+ 호스트+ 포트)의 리소스만 공유 가능함 -> 해로울 수 있는 문서를 분리함으로써 공격(해킹 등)받을 수 있는 경로를 줄여줌 다른 출처의 리소스를 받아오고 싶다면 CORS 사용 CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유) 추가 HTTP 헤더를 사용하여 다른 출처의 특정 자원에 접근할 수 있는 권한 부여 CORS 동작 방식 1. 프리플라이트 요청(Preflight Request) 실제 요청을 보내기 전 OPTIONS 메서드로 사전 요청을 보내 ..

점진적인 개선을 보여주는 사례 연구(명령행 인수 구문분석기) 확장성이 부족했던 모듈을 개선하고 정리한 단계들을 소개 프로그램을 짜다 보면 종종 명령행 인수의 구문을 분석할 필요가 있음 - 이미 짜여진 유틸리티 사용 - 내 프로그램에 맞도록 직접 작성한 유틸리티(Args) 사용 처음부터 깨끗한 코드를 작성할 수는 없음 책을 쓸 때 1차 초안, 2차 초안, ... , 계속 고쳐서 최종안을 만들듯이 깨끗한 코드를 짜려면 일단 어떻게든 코드를 작성한 뒤 정리해야 한다 Args 1차 초안의 문제점 - 너무 많은 인스턴스 변수 개수 - 'TILT' 같은 희한한 문자열 - HashSets, TreeSets, try-catch-catch 블록 등 => 지저분한 코드 함수 이름, 변수 이름에 신경썼으며, 어설프지만 구조..

React 특징: 단방향 데이터 흐름(one-way data flow) 데이터 흐름이 하향식(top-down) 데이터를 전달하는 주체는 부모 컴포넌트임 제작은 상향식(Bottom-up) 컴포넌트부터 제작하고 조립하여 페이지를 만듦. 테스트가 쉽고 확장성이 좋음 State 끌어올리기(Lifting state up) : 상위 컴포넌트의 상태 변경 함수를 props로 전달해 하위 컴포넌트에서 상위 컴포넌트의 상태 바꾸기 Side effect(부수 효과) 함수 내에서의 구현이 함수 외부에 영향을 끼치는 것 ex) fetch API나 LocalStorage를 사용해 데이터를 가져오기, 이벤트를 활용해 DOM 조작하기, AJAX 요청, 타이머 API 사용(setTimeout) => React에서 이를 다루기 위한 ..

주소창에 URL을 입력하면 URL의 root-endponint로 GET 요청 테스트를 위해 GET 말고 다른 요청을 보내고 싶다면 개발자도구- 콘솔창에서 Web API fetch를 이용해야함 -> 매번 콘솔창에 들어가서 코드를 입력하는 것이 번거롭기 때문에 HTTP 요청을 테스트할 수 있는 API 도구 사용 CLI 환경 - curl, wuzz GUI 환경 - Postman, Insomnia Postman 1. 회원가입 2. Workspace -> My Workspace 3. 탭 추가 4. HTTP 메서드 선택 -> url 입력 -> 옵션 추가(Params, Headers, Body 등) 5. 요청 보내기(Send) Open Weather Map : 무료 날씨 API 마이 페이지의 My API keys에서..

객체는 처리의 추상화다. 스레드는 일종의 추상화다. - James O. Coplien 동시성과 깔끔한 코드는 양립하기 어려움. 여러 스레드를 동시에 돌리는 이유와 그것의 어려움 => 깨끗한 코드를 작성하는 법, 동시성을 테스트하는 방법과 문제점 기술 동시성이 필요한 이유 동시성은 무엇과 언제의 결합을 분리 -> 거대한 루프 하나가 아닌 작은 협력 프로그램 여럿으로 보여서 시스템을 이해하기 쉽고, 문제를 분리하기 쉬움 구조 개선, 효율 증가, 응답 시간과 작업 처리량 개선(많은 데이터를 짧은 시간에 처리하기 위해) 미신과 오해 - 동시성은 항상 성능을 높여주지는 않는다 대기 시간이 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우 - 동시성을..

창발성 : 하위 계층(구성 요소)에 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상 창발적 설계로 깔끔한 코드를 구현하기 착실히 따르기만 하면 우수한 설계가 나오는 규칙 네 가지(중요도순) - 켄트 벡 - 코드 구조와 설계를 파악하기 쉬워짐 - SRP(단일 책임 원칙), DIP(의존 관계 역전)를 적용하기 쉬워짐 (DIP: 저수준 모듈이 고수준 모듈에 의존하게 하는 것) - 우수한 설계의 창발성을 촉진 1. 모든 테스트를 실행하기 테스트(검증)가 불가능한 시스템은 출시하면 안 된다 테스트가 가능한 시스템을 만드려고 하면 테스트가 가능하도록 코드를 쉽게 작성하게 됨 결합도가 높으면 테스트 케이스를 작성하기 어려움 -> DIP 원칙을 적용하고 의존성 주입(DI), 인터페이스,..

"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다." - 레이 오지 Ray Ozzie, 마이크로소프트 최고 기술 책임자 CTO 도시 = 시스템 한 사람이 도시를 관리하기는 어려움 수도 관리팀, 전력 관리팀, 교통 관리팀, 치안 관리팀 등 각 분야를 관리하는 팀이 있음 도시가 돌아가는데 적절한 추상화와 모듈화되어 있어 구성요소가 효율적으로 동작함 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워짐 그렇다면 시스템(높은 추상화) 수준에서도 깨끗함을 유지하는 방법은? 시스템 제작과 시스템 사용을 분리 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해..

클래스 체계 표준 자바 관례 1. 변수목록 - 정적 공개 상수 static public - 정적 비공개 변수 private - 비공개 인스턴스 변수 (공개 변수가 필요한 경우는 거의 없음) 2. 공개 함수 공개 함수가 호출하는 비공개 함수 (추상화 단계가 순차적으로 내려감) 캡슐화 변수와 유틸리티 함수는 공개하지 않는 편이 낫지만 반드시 숨겨야하는 것은 아님 테스트(TDD)는 매우 중요하기 때문에 필요하다면 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 함 - 그러나 캡슐화를 푸는 것은 최수의 수단이기 때문에 비공개 상태를 유지할 방법을 강구해야함 클래스는 작아야 함 클래스를 만들 때 가장 중요한 것이 크기임(함수와 마찬가지) '책임'에 따라 크기를 판단 (RDD 책임..