API : 클라이언트와 서버의 통신을 담당 요청/응답 시 지켜야할 규약 -> 혼자서 웹 사이트를 만들고 관리한다면, 어떻게 설계하고 구현하든 상관 없으나 일반적인 회사에서 진행하는 서비스 개발은 대부분 팀 단위로 진행하기에 사소한 것 하나라도 규칙이 있어야 소통이 원활함 REST API(Representation State Transfer API) : 웹에서 사용되는 데이터나 자원(resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식 "정확한 소통을 위한 최소한의 규칙" REST 성숙도 모델 로이 필딩 (Roy Fielding)이 논문에서 제시한 REST 방법론을 보다 더 실용적으로 적용하기 위해 레오나르드 리차드슨(Leonard Richardson)이 만..
웹 애플리케이션 아키텍처 주소창에 주소를 입력했을 때 흐름 LAN > ISP > Internet > DNS > Internet > AWS (Local Area Network, Internet Service Provider, , Domain Name System, , Amazon Web Service) 클라이언트 : 인터넷에 연결된 사용자의 디바이스 또는 웹에 접근할 수 있는 소프트웨어를 뜻함 리소스를 받아서 활용하는 주체 필요한 데이터가 앱 내에 모두 있어서 서버가 존재하지 않는 경우, 데이터 추가가 필요할 때마다 앱을 업데이트 해야함 클라이언트-서버 아키텍처(Client-Server Architecture) = 2-Tier Architecture 빈번한 데이터 업데이트가 필요한 경우 '리소스를 제공(전..
Redux state(전역 state) : 수 많은 state를 관리하기 위해 탄생. store로 접근 가능 Local/Redux state 데이터 사용 주기에 따라 사용 권장 꼭 아래처럼 사용하라는 것은 아님. 개인이 판단하여 사용 Short-term : 프로젝트 전역적으로 영향을 주지 않는 데이터. 빠르게 변화하는 데이터 ex) UL element, form 입력 정보 상태 변화, 텍스트 필드 문자 등 -> Local state Medium-term : 프로젝트에 전역적으로 영향을 주는 데이터 앱 실행 동안 유지되거나 API 통해서 로드된 데이터, 새로고침 전까지 유지되어야 하는 데이터 ex) 전역으로 사용되는 유저 정보, submit 양식을 제출하여 사용자 정보를 업데이트하는 경우 -> Redux ..
테스트 주도 개발 TDD(Test Driven Development) TDD 법칙 세 가지 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다 3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다 깨끗한 테스트 코드 유지하기 테스트 코드를 잘 설계하거나 주의해서 분리할 필요 없이 그저 돌아만 가도록 작성. 테스트를 안 하는 것보다 지저분한 테스트 코드라도 있도록 -> 테스트를 하나마나한, 안하느니만 못한 결과를 낳음 실제 코드가 진화하면 테스트 코드도 변해야 하는데 테스트 코드가 지저분할수록 변경하기 어려워짐 -> 실제 코드 작성 시간보다 테스트 케이스를 추가하는 시간이 더 걸림 -> 테스트 ..
시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다 - 패키지를 사거나 - 오픈 소스를 이용하거나 - 사내 다른 팀이 제공하는 컴포넌트 사용 위 외부 코드를 우리 코드에 깔끔하게 통합해야 함 소프트웨어 경계를 깔끔하게 처리하는 기법, 기교 1. 외부 코드 사용하기 패키지, 프레임워크 제공자는 더 많은 환경에서 돌아가게 하기 위해 적용성을 최대한 넓히려 함 사용자는 자신의 요구에 집중하는 인터페이스를 바람 => 서비스가 사용자에게 필요하지 않은 기능까지 제공함 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의. (공개API로 넘기거나 반환값으로 사용하지 않도록 해야함) 2. 경계 살피고 익히기 외부 코드를 사용하면 적은 시간에 더 많은 기능을 출시하..
상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다 = 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 어렵다 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다 오류를 처리하는 기법과 고려 사항 1. 오류 코드보다 예외를 사용할 것 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법 -> 호출자 코드가 복잡해짐 오류가 발생하면 예외를 던지기(try-catch) 2. Try-Catch-Finally 문부터 작성할 것 try-catch 구조로 범위를 정의하고, TDD(테스트주도개발방식)를 사용해 필요한 나머지 논리를 추가 강제로 예외를 일으키는 테스트 케이스를 작성 후 테스트를 통과하게 코드를 작성하기를 권장 -> try 블록의 ..
React의 대표적인 특징 1. 단방향(하향식) 데이터 흐름 원칙(One-way data flow) React is all about one-way data flow down the component hierarchy 2. 상향식(bottom-up)으로 앱을 만듦 페이지를 만들기 전에 컴포넌트를 먼저 만들고 조립 -> 테스트가 쉽고 확장성이 좋음 3. 단일 책임 원칙 하나의 컴포넌트는 하나의 일만 함 State(상태) 컴포넌트 내부에서 변할 수 있는 값 변화가 필요한 데이터를 state로 저장하여 사용 상위 컴포넌트의 state를 하위 컴포넌트에 props으로 전달 Props(속성) 컴포넌트 외부로부터 전달받은 변하지 않는 값 컴포넌트가 최초 렌더링될 때 화면에 출력하고자 하는 데이터를 담은 초깃값으로 ..
MPA(Multiple Page Application) : 페이지마다 새로운 html을 받아와 화면에 보여주는 방식(깜빡인다고 표현함) 웹사이트가 복잡해지고 애플리케이션 형태를 가지게 되면서 사용자와 서비스 사이의 상호작용이 많아지고 트래픽 증가, 느린 반응성으로 사용자 경험의 저하를 야기시킴 (Header, Navigation Bar 등 중복되는 요소들을 매번 불러오는 것은 불필요한 트래픽 발생시킴) SPA(Single Page Application) : html 문서 전체가 아니라 필요한 데이터만 받아 업데이트하는 방식 업데이트에 필요한 데이터만 서버에서 전달받아 동적으로 HTML요소를 생성해서 화면에 보여주는 방식 JS와 historyAPI를 이용해 구현할 수 있는데 이를 쉽게하도록 도와주는 라이브..
변수를 비공개private로 정의하는 이유: 남들이 변수에 의존하지 않게하기 위해 그러면 get함수와 set함수를 공개public하여 비공개 변수를 위부에 노출하는 이유는? 자료 추상화 자료를 세세하게 공개하기보다 추상적인 개념으로 표현하는 편이 좋음 (구현 감추기) 추상화하기 위해 인터페이스나 get/set 함수만 추가하는 것은 좋지 않음 객체를 포함하는 자료를 표현할 방법을 고민해야 함 자료/객체 비대칭 자료 구조와 객체는 반대임. 자료 구조는 자료를 그대로 공개하며 별다른 함수를 제공하지 않음 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개 자료 구조(절차적)에 새 함수를 추가- 영향 없음, 새 클래스 추가- 함수 수정 객체(다형적)에 새 함수를 추가- 기존 클래스 전부 수정, 새 클..
코드가 깔끔하고, 일관적이며, 꼼꼼하고, 질서 정연하다는 인상 주기 코드 형식을 맞추기 위해 간단한 규칙을 정하고 그 규칙을 따라야한다. - 규칙을 자동으로 적용하는 도구를 활용하기도 함 형식을 맞추는 목적 전문 개발자의 일차적인 의무: 의사소통 처음 코드에서 시간이 지나 원래 코드를 찾아보기 어려울 정도로 코드가 바뀌어도 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다 원활한 소통을 장려하는 코드 형식 적절한 행 길이를 유지할 것 반드시 지켜야하는 규칙은 아니지만 바람직한 규칙임 일반적으로 큰 파일보다 작은 파일이 이해하기 쉬움 프로젝트의 파일 길이를 조사했을 때 대부분 200줄 정도의 파일로도 커다란 시스템을 만드는데 충분했음(97p) 1. 신문 기사처럼 작성..