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. 경계 살피고 익히기 외부 코드를 사용하면 적은 시간에 더 많은 기능을 출시하..