PostgreSQL와 Amazon RDS를 연결해 서버를 구축하고 테스팅을 하면서 직접 데이터를 Insert하고 Delete하는 과정에서 생길 수 있는 문제들을 깨닫게 되었다. 추후에 서버를 배포하게 되었을 때 유저들 데이터로 직접 테스팅을 할 수 없기 때문에 Postgres Local DB를 구축하고 연결하였다 .

💜 과정

⭐ PostgreSQL 설치하기

• https://www.postgresql.org/download/ 링크로 들어가서 본인의 os에 맞게 설치한다.

  ⭐ PostgreSQL 설치 확인하기

• window에서는 SQL Shell (psql)을 사용해서 설치가 되었는지 확인한다.

⭐ DataGrip 연결하기

• Name: 원하는 이름
• Host: localhost
• Port: 5432
• User: postgres

⭐ DataGrip Data 추출하기

◼ Table 구조

• Table 구조를 SQL Script로 추출해서 Table 구조를 옮길 수 있다.

◼ Table 내의 Data

• Data를 추출하고 싶은 Table을 클릭하여 Export Data to File을 클릭하면 해당 Table의 Data를 SQL문으로 추출하여 Data를 옮길 수 있다.

⭐ Database 연결하기

• .env파일에 위에서 연결한 Postgres DB의 정보를 입력한 후 연결하면 현재 DataGrip에 연결한 DB에서 자유롭게 Data확인이 가능하다.

DEV_DB_USER=postgres
DEV_DB_HOST=localhost
DEV_DB=postgres
DEV_DB_PASSWORD=password

💜 결과

배포용 서버를 테스팅 서버로 이용하게 되면 배포 후 테스팅을 실제 유저의 정보로 해야되는 문제가 생길 뿐만 아니라 안전성에도 문제가 생기게 된다.

로컬 서버를 분리함으로써 Database 구조가 변경될 때 로컬 DB에서 충분히 안정성을 검사하고 배포하는 과정을 거칠 수 있다.

ELB는 Elastic Load Balancer는 AWS의 로드 밸런서 서비스 입니다.

로드밸런서의 주요 기능은 서버 부하 분산, 즉 로드밸런싱으로 특정 서버에 부하가 몰리지 않도록 적절히 분산을 시킵니다. 로드밸런서가 사용자의 접근을 적당한 서버로 보내주는 역할을 합니다.

2. ELB의 유형

1) Application Load Balancer(ALB)

Application Layer: 사용자가 UI로 접하는 응용 프로그램과 관련된 계층으로 HTTP, FTP, DHCP, SMTP, DNS등이 있습니다.

• OSI 7 Layer의 7계층에 해당하는 Application Layer의 특성을 이용하는 로드밸런서
• 단순 부하분산뿐만 아니라 HTTP의 헤더 정보를 이용해 부하분산을 실시합니다.

2) Network Load Balancer(NLB)

Transport Layer: 송신자와 수신자의 논리적 연결을 담당하는 부분으로, 신뢰성있는 연결을 유지할 수 있도록 도와줍니다. 즉 endpoint(사용자)간의 연결을 생성하고 데이터를 얼마나 보냈고 받았는지, 제대로 받았는 지등을 확인합니다. TCP와 UDP가 대표적입니다.

• OSI 7 Layer의 4계층에 해당하는 Transport Layer의 특성을 이용하는 로드밸런서
• TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시

3. 로드밸런싱의 기능

NAT(Network Address Translation)

• 사설 IP주소를 공인 IP주소로 바꾸는 데 사용하는 통신망의 주소 변조기입니다.

  Tunneling

• 인터넷 상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 합니다.
• 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있습니다.

  DSR(Dynamic Source Protocol)

• 로드 밸런서 사용 시 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP주소가 아닌 클라이언트의 IP주소로 전달해서 네트워크 스위치를 거치지않고 바로 클라이언트를 찾아갑니다.

4. 서버 확장 방식

1) Scale Up

• 성능이나 용량 증강을 목적으로 하나의 서버에 디스크를 추가하거나 CPU나 메모리를 업그레이드 시키는 것
• 기존의 하드웨어를 보다 높은 사양으로 업그레이드하는 방식
• 수직 스케일링(Vertical Scaling)

  2) Scale out

• 기존의 서버와 같은 사양 또는 비슷한 사양의 서버 대수를 증가시키는 방법으로 처리 능력을 향상 시키는 것
• 여러 대의 서버가 분산처리할 수 있도록 요청을 나누어주는 방식
• 수평 스케일링(Horizontal Scaling)
• 서버가 여러 대가 되기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 로드밸런싱 필수 동반

5. ELB 관련 실습

1) 인스턴스 생성

Ubuntu Server 20.04 LTS (HVM), SSD Volume Type 선택 t2.micro 선택 나머지는 기본 설정 그대로!

2) 인스턴스 연결

해당 인스턴스 마우크 오른쪽 클릭 후 연결 선택 - 다음페이지도 연결 선택 이 화면이 나온다면 연결 성공!

sudo apt update sudo apt install apache2 php

위의 코드 입력 후 잘 연결되었는지 확인을 위해 해당 인스턴스의 퍼블릭 IP주소를 입력해 접속해봅니다. Ubuntu Default Page가 나온다면 연결 성공!

sudo vim /var/www/html/index.php

위 코드로 파일을 하나 생성합니다.

<?php
print($_SERVER['SERVER_ADDR']);
?>             

파일(index.php) 안에 위 코드를 입력하면 현재 우리가 실행하고 있는 웹페이지가 어떤 내부 IP를 가지고 있는지를 출력합니다.

해당 인스턴스의 퍼블릭 IP주소/index.php를 입력해서 인스턴스의 프라이빗 IPv4주소가 출력되면 연결 성공!

이 인스턴스 하나로 서비스를 하다가 부족하다고 느끼면 로드밸런서를 웹서버 앞에두고 부하를 분산시킬 수 있습니다. 트래픽들이 들어오게 되면 그 트래픽을 Load Balancer가 모두 받고 각각의 인스턴스로 보내게 됩니다. 서로 같은 속성을 가지고 있는 인스턴스들을 그룹핑하는 Target Group을 만들고 그들을 Load Balancer에 등록해 Target Group을 대상으로 트래픽을 보내주게 됩니다.

3) 대상 그룹 등록

메뉴에서 로드 밸런싱 밑에 대상 그룹 클릭

다음 선택 후 해당 인스턴스를 체크하고 '아래에 보류 중인 것으로 포함'클릭 후 '대상 그룹 생성' 선택하면 해당 인스턴스를 대상 그룹에 등록 완료!

4) 대상 그룹 로드밸런서에 연결

메뉴에서 로드 밸런싱 밑에 대상 로드밸런서 클릭 Application Load Balancer 생성

1. 네트워크 매핑 모두 선택
2. 보안 그룹 - 새 보안 그룹 생성 후 선택
3. 리스너 및 라우팅 - HTTP / 81(ELB를 위한 방화벽) / TG 선택
4. 로드 밸런서 생성

해당 로드 밸런서의 DNS이름:81로 접속하면 Ubuntu Default Page가 나옵니다. DNS이름:81/index.php를 입력한 후 인스턴스의 프라이빗 IPv4주소가 출력되면 ELB에 인스턴스 연결 완료!

-> 현재는 하나의 인스턴스만 연결된 상태 - 오히려 속도가 느려진다.

5) 복수 개의 인스턴스 연결

기존 인스턴스의 이미지 생성(이름만 적고 생성 누르기)

메뉴 - 이미지 - AMI를 선택하면 방금 생성한 이미지를 볼 수 있습니다. 해당 이미지 마우스 오른쪽 클릭 후 시작하기 클릭 후 아까 처음 인스턴스 생성과 똑같은 조건의 인스턴스를 생성해줍니다.

로드밸런스에 연결되어있는 대상 그룹 TG에 해당 인스턴스를 추가해줍니다. 대상 등록을 선택해 방금 생성한 인스턴스를 등록합니다. => 인스턴스 2개가 TG라는 그룹을 통해서 ELB에 연결됩니다.

6) ELB주소로 접속 후 확인

해당 로드 밸런서의 DNS이름:81/index.php로 접속후 새로고침을 하면 로드밸런서가 들어오는 트래픽을 연결되어 있는 인스턴스들에게 분산하고 있는 것을 볼 수 있습니다.

참고자료 https://nesoy.github.io/articles/2018-06/Load-Balancer https://junghyungil.tistory.com/151 https://www.youtube.com/watch?v=s9FHdj6jd_U&t=790s

이벤트가 발생했을 때 미리 지정해둔 작업을 수행하는 방식

1. 이벤트 리스너에 콜백 함수 등록

2. 이벤트 발생 (시스템 -> 이벤트 리스너)

3. 등록된 콜백 함수 호출 (이벤트 리스너 -> 시스템)

예시)

출력 결과:

시작 끝 3초 후 실행

setTimeout : 특정 밀리초이후에 코드를 실행

• 이벤트 루프 : 이벤트 발생 시 호출할 콜백 함수들을 관리하고, 호출된 콜백 함수의 실행 순서를 결정하는 역할, 노드가 종료될 때까지 이벤트 처리를 위한 작업을 반복

  • 태스크 큐 : 이벤트 발생 후 호출되어야 할 콜백 함수들이 기다리는 공간,
  • 백그라운드 : 타이머나 I/O 작업 콜백 또는 이벤트 리스너들이 대기하는 곳

** run 함수 이동경로**

1. 호출 스택에 쌓인다.
2. setTimeout 실행 시 콜백 run은 백그라운드로 이동한다.
3. 백그라운드에서 3초 후 태스크 큐로 보낸다.
4. 호출 스택 실행이 끝나 비워지면 이벤트 루프가 태스크 큐의 콜백(run)을 호출 스택으로 올린다.
5. 호출 스택에서 비워진다.
6. 이벤트 루프는 태스크 큐에 콜백이 들어올 때까지 대기한다.

논블로킹 I/O

논블로킹 : 이전 작업이 완료될 때까지 멈추지 않고 다음 작업을 수행함

I/O : Input / Ouput

출력 결과:

시작 작업 끝 다음 작업

longTasking 함수가 종료되기 전까지 console.log("다음 작업")이 호출되지 않는다.

출력 결과:

시작 다음 작업 작업 끝

setTimeout(콜백, 0) : 코드를 논블로킹으로 만들기 위해 사용되는 기법 중 하나

밀리초를 0으로 설정했지만 노드에서는 기본적인 지연 시간이 있으므로 바로 실행되지 않는다.

- 싱글스레드

하나의 프로세스에서 하나의 스레드 실행

• 싱글 스레드, 블로킹 모델

점원 한명이 주문을 받아 주방에 넘기고, 주방에서 요리가 나오면 손님에게 서빙을 한다. 그 후 다음 손님의 주문을 받는다.

• 싱글 스레드, 논블로킹 모델

  노드가 채택하고 있는 방식

점원이 한 손님의 주문을 받고, 주방에 주문 내역을 넘긴 뒤 다음 손님의 주문을 받는다. 그 후 주방에서 요리가 완료되면 완료된 순서대로 손님에게 서빙한다.

*프로세스와 스레드의 차이

프로세스 : 운영체제에서 할당하는 작업의 단위

• 노드나 인터넷 브라우저 같은 프로그램은 개별적인 프로세스
• 프로세스 간에는 메모리 등의 자원을 공유하지 않는다.

  스레드 : 프로세스 내에서 실행되는 흐름의 단위

• 하나의 프로세스는 스레드를 여러 개 가질 수 있다.
• 스레드들은 부모 프로세스의 자원을 공유한다. (같은 메모리에 접근 가능)

노드는 스레드를 늘리는 대신, 프로세스 자체를 복사해 여러 작업을 동시에 처리하는 멀티 프로세싱 방식

*멀티스레드와 멀티 프로세싱의 차이

멀티 스레드 : 하나의 프로세스가 여러 개의 작업을 각각 스레드를 이용하여 동시에 작동시킬 수 있다.

멀티 프로세싱 : 하나의 응용 프로그램을 여러 개의 프로세스로 구성하여 각 프로세스가 하나의 작업을 처리하도록 한다.

1.2.1 소프트웨어 재사용

가) 소프트웨어 재사용 개요

1. 소프트웨어 재사용 배경

• 소프트웨어 위기로 인한 품질 및 생산성 저하
• 소프트웨어 품질 확보 노력

2. 소프트웨어 재사용 정의

• 사용 소프트웨어 개발관련 지식을 표준화하여 개발 생산성을 높이기 위해 반복적으로 사용하기에 적합하도록 구성하는 방법
• 품질을 인정받았던 소프트웨어 전체 또는 일부분을 다시 사용하여 신규 개발되는 소프트웨어의 신뢰성을 높이고 개발 비용을 감소시켜주는 방안

3. 소프트웨어 재사용의 목적

   신뢰, 확장, 생산

• 신뢰성 : 사전 성능 검증됨
• 확장성 : 검증된 기능 기반으로 upgrade 용이
• 생산성 : 전체적 개발 프로세스 향상

나) 소프트웨어 재사용의 대상

• 일반적인 지식
• 설계 정보
• 데이터 정보
• 프로그램 코드

다) 소프트웨어 재사용의 원칙

모범하소 자신일

• 모듈성 : 최소한의 결합도 및 최대한의 응집력
• 범용성 : 일반적으로 활용될 수 있는 정도
• 하드웨어 독립성 : 가능한 실행 하드웨어 기종과 무관해야 함
• 소프트웨어 독립성 : OS 또는 DBMS와는 무관하게 운영해야 함
• 자기문서화 : 모듈의 정확한 기능, 인터페이스를 기술
• 신뢰성 : 품질을 믿고 사용할 수 있어야 함
• 일반성 : 많은 개발자들에게 공통적으로 필요하고 사용 가능해야 함

+) OS (Operating System) : 운영체제 DBMS (Data Base Management System) : 데이터베이스 관리 시스템

라) 실무에서 재사용 구현의 문제점

• 공통으로 사용할 수 있는 소프트웨어 모듈을 발견하기 어려움
• 소프트웨어 표준화 부족
• 부품이 개발비가 더 들 수 있음
• 효과가 오랜 시간 경과 후 나타남
• 현존한느 소프트웨어 부품에서 재사용 부품의 추출이 비현실적

마) 소프트웨어 재사용의 장애요인 및 대책

1. 소프트웨어 재사용의 장애요인

• 관리자와 개발 담당자들의 거부 반응
• 사회적 또는 법적 장애

2. 소프트웨어 재사용의 장애요인 제거 대책

• 기술적 방안 : 재사용 소프트웨어 라이브러리 구축, 개발 방법론 활용
• 관리, 제도적 방안 : 보상제도의 확립, 조직의 변화

바) 재사용 적용 시 고려사항

• 생산성 향상이 가능해야 함
• 재사용 문화 조성을 위한 제도 정착
• 초기 투자를 통한 재사용 환경 구축
• 도구의 지원이 있어아 함
• 지속적인 라이브러리의 개선 및 보강

  사) 소프트웨어 재사용의 효과

• 높은 품질의 소프트웨어 생산을 위한 공유 및 활용효과
• 시스템 개발에 다한 정보공유

1.2.2 역공학

가) 역공학의 정의

• 소프트웨어 공학의 한 분야로 이미 만들어진 시스템을 역으로 추척하여 처음의 문서나 설계기법 등의 자료를 얻어 내는 일
• 시스템을 이해하여 수정하는 소프트웨어 유지보수 단계에서 수행
• 소프트웨어 생명주기 마지막 단계에서 얻어지는 포로그램 또는 문서 등을 이용, 초기 단계의 산출물에 해당하는 정보 또는 문서를 만들어내는 일

<역공학의 Input / Output>

• Input : 원시코드, 작업절차, 라이브러리 등 입출력 형태의 자료 문서
• Output : 구조도, 자료 흐름도, 제어 흐름 그래프, 개체 관계도

나) 역공학이 필요한 이유

• 가동중인 시스템의 유지보수가 어려운 경우
• 시스템 효율이 저하된 경우
• 파일 시스템으로 개발된 업무를 관계형 데이터베이스로 재구축 하려는 경우
• 기본 메인 프레임을 다운사이징 하는 경우

다) 역공학의 장점

• 개발된 소프트웨어의 분석을 도와줌
• 유지보수성 향상
• 기존 시스템 정보를 Repository에 보관하여 CASE 사용을 용이하게 함

라) 역공학의 종류

• 논리역공학 : 원시코드로부터 정보를 추출해 물리적 설계 정보저장소에 저장
• 자료역공학 : 기존 데이터베이스를 수정하거나 새로운 데이터베이스 관리시스템으로 전이하는 역할 수행

1.1.1 소프트웨어 공학의 배경과 목적

가) 소프트웨어 공학 소개

P.P.T

• 프로세스 (Process)
• 인력 (People)
• 인프라 기술 (Technology)

나) 소프트웨어 공학 배경

다) 소프트웨어 공학의 4가지 중요요소

• 방법

• 도구
• 절차
• 사람

1. 방법 : 프로젝트 계획 수립과 추정, 시스템과 소프트웨어 분석, 자료구조

2. 도구 : 일을 수행할 때 생산성 혹은 일관성을 목적으로 사용하는 방법 들을 자동화나 반자동화 시켜 놓은 것

3. 절차 : 방법 + 도구 -> 소프트웨어 합리적 개발을 가능하도록 함

4. 사람

1.1.2 소프트웨어 개발 생명주기

가) 정의

: 사용자 환경 및 문제점 이해부터 운용/유지 보수까지의 모든 과정

• 일반적인 소프트웨어 생명주기

타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수

나) 목적

• 프로젝트 관리

  다) 소프트웨어 생명주기 선정

• 선택한 모델은 프로젝트에 존재하는 리스크 / 불확실성을 최소화 시킬 수 있어야 한다.

• ex) 폭포수 모델, 프로토타입 모델, 진화 모델, 점증적 모델

라) 소프트웨어 생명주기 모델 종류

1. V 모델

• 시스템의 요구사항이 모두 식별되고 명확할 때 이상적인 생명주기 모델
• 프로젝트에 적용, 관리하기가 용이
• 프로젝트의 검증 및 확인을 강조하는 모델
• 개발 활동과 이에 해당하는 테스트 활동이 병행됨
• 테스트 동안 결함이 발견되었을 경우, 개발 활동의 어느 단계를
  재 수행되어야 하는 지 알 수 있다.

2. VP 모델 (V Model with Prototyping) Prototyping : 시스템에 대한 이해 또는 리스크, 불확실성 요소와 같은 이슈를 해결하기 위해 시스템 혹은 그 일부를 빠르게 개발하는 방법

• 불확실성 요소나 리스크를 줄일 수 있음
• 개발자와 고객의 공통적인 이해를 이끌어 낼 수 있음

프로토타입 기법의 접근방법

1) 적용 가능한 해결책 조사, 이를 적용

• 불확실성 요소를 정의
• 해결책 찾기
• 적용하기 위한 방법 정의
• 해결책 적용 (반복 수행)
• 그 결과를 통해 불확실성 요소의 원인 찾기

-> 해결하려는 문제가 명확하지 않은 경우

2) 여러가지 선택 가능한 해결책을 열거, 정해진 기준에 따라 이를 평가

• 불확실성 요소를 정의
• 선택 가능한 해결책 열거
• 선택 기준 정의
• 선택 기준에 따라 해결책 평가
• 가장 적합한 해결책 선택

-> 적용하려는 해결책에 리스크나 불확실성 요소가 존재하는 경우

3. 점증적 모델

• 핵심이 되는 부분 먼저 개발 후 나머지 기능 구현
• V 모델, VP 모델 모두 적용 가능
• 시스템 개발 시간을 줄일 필요가 있는 경우 유용
• 시간이 지남에 따라 개선 여지가 있는 경우 유용

4. 진화 모델

• 전체 시스템에 대한 개발 단계 여러 번 반복
• 하나의 시스템 개발되어 사용, 변경 사항 도출 -> 다음 시스템 개발에 반영
• 시스템 개발 시간을 줄일 필요가 있는 경우 유용
• 제품의 개선이 지속적으로 요구되는 경우 유용

*5. 혼합 모델 * 점증적 모델 + 진화 모델 -> 기존의 기능 향상, 새로운 기능 추가

• 시스템 초기 교육 가능 - 실무에 필요한 개선사항 도출
• 개발 기간 단축 - 경쟁력 강화
• 전문 분야별로 나눠서 시스템 개발 가능

1.1.3 소프트웨어 개발 방법론

가) 소프트웨어 개발 방법론의 필요성

1. 개발 생산성 향상
2. 효과적인 프로젝트 관리
3. 의사소통 수단 제공
4. 일정 수준의 품질 보증

나) 소프트웨어 개발 방법론 비교

구정객C

• CBD : Compoenet Based Development

다) 소프트웨어 개발 단계

: 소프트웨어 생명주기에 따라 정의

요구사항 분석 -> 설계 -> 구현 -> 테스팅

1. 요구사항 분석

• 개념적 단계
• 무엇을 개발할 것인지 정확히 결정
• 사용자의 요구를 이해하는 단계
• 개발 비용을 감소시킬 수 있는 단계
• 전체 소프트웨어 개발 기간과 비용의 초과, 품질 저하 미연에 방지 가능

2. 설계

• 물리적 실현의 첫 단계
• 시스템 구조 결정
• 품질에 직접적 영향 줌
• 설계가 제대로 되지 않으면 시스템 안정감 저하 -> 유지보수 어려움

3. 구현

• 목표 : 요구사항을 만족할 수 있도록 프로그램 하는 것
• 상세 설계나 사용자 지침서에 기술된 것과 일치하도록 개발
• 코딩 표준 정하고 이를 기반으로 명확하게 코드 작성

4. 테스팅

• 정해진 요구 만족하는지, 예상과 실제 결과의 차이가 어떠한지 검사하고, 평가하는 일련의 과정
• 소프트웨어의 품질을 확보하기 위해 결함을 찾아내는 일련의 작업
• 개발한 소프트웨어 품질에 대한 평가와 품질 향상을 위한 수정 작업 포함

1.1.4 애자일 개발 방법론

가) 애자일 방법론 종류

• 스크럼 (Scrum)
• 익스트림 프로그래밍 (eXtreme Programming, XP)

나) 애자일 개발 방법론 - XP

1. XP 개요

• 중소규모 개발 조직에 적합한 경량화된 개발방식
• 반복적 개발방법론의 일종

2. XP 개발절차 및 용어

• 유저스토리 : 요구사항 수집, 의사소통의 도구, 기능단위의 필요한 내용 기재
• 스파이크 : 어려운 요구사항 혹은 잠재 솔루션을 고려한 간단한 프로그램 목적) 사용자 스토리의 신뢰성 증대, 기술 문제의 위험 감소
• 릴리즈 계획 : 전체 프로젝트에 데한 배포 계획 수립, 반복들을 균일하게 유지
• 승인 테스트 : 릴리즈 전 인스 테스트, 고객이 직접 수행
• 작은 릴리즈 : 소규모로 빈번하게 배포 -> 고객에게 이득을 조기에 제공 가능

3. XP 가치

   의사소통, 단순성, 피드백, 용기, 존중

• 의사소통 : 팀 단위 개발에서 가장 중요, 고객, 개발자, 관리자들 간의 의사소통을 통해 문제를 해결하고 팀 빌딩을 강화해야 함
• 단순성 : 불필요한 복잡성 제거 - 설계를 단순,명확하도록 유지
• 피드백 : 최대한 많은 피드백을 만들어 개선에 활용
• 용기 : 요구사항 및 기술 변경에 용감하게 대처, 단순함 추구, 피드백 강화
• 존중 : 팀에 속한 사람들을 존중

4. XP의 실천방법

다) 스크럼 (SCRUM)

1. 스크럼 개요

• 프로젝트 관리를 위한 애자일 방법론
• 경험적 관리기법의 대표적인 형태

<스크럼 역할자 유형>

P.O / S.M / S.T => SM POST

제품 책임자 (Product Owner) - 팀장

• 제품 기능목록에 해당하는 제품 백로그 만듦
• 우선순위 조정
• 새로운 항목 추가
• 스프린트 계획 수립 시점 : 핵심 역할, 시작 후 : 팀의 운영에 관여하지 않음

스크럼 마스터 (Scrum Master) - 관리자

• 팀의 업무를 방해하는 요소 제거에 노력
• 원칙과 가치를 지키면서 팀이 개발을 진행할 수 있도록 지원

스크럼 팀 (Scrum Team) - 개발자

• 일반적으로 최소 5명 최대 9명
• 사용자 스토리를 사용하여 한 스프린트 동안 개발할 기능 도출

2. 스크럼 프로세스

• 스프린트 : 1 ~ 4주 단위의 반복개발기간
• 3가지 미팅 : 일일 스크럼, 스프린트 계획, 스프린트 리뷰
• 3가지 산출물 : 제품 백로그, 스프린트 백로그, 소멸 차트

<스크럼 프로세스 산출물>

제품 백로그, 스프린트 백로그, 소멸 차트

• 제품 백로그 제품에 담고자 하는 기능의 우선순위를 정리한 목록 P.O가 주로 우선순위를 결정
• 스프린트 백로그 하나의 스프린트동안 개발할 목록 각 과업은 시간 단위로 추정
• 소멸 차트 : 개발을 완료하기까지 남은 작업량을 보여주는 그래프

<스크럼 프로세스 산출물>

스프린트 계획, 일일 스크럼, 스프린트 리뷰

• 스프린트 계획 각 스프린트에 대한 목표를 세우고 제품 백로그부터 스프린트에서 진행할 항목을 선택
• 일일 스크럼 : 매일 진행하는 프로젝트 진행상황을 공유하는 회의
• 스프린트 리뷰 : 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의 스크럼 팀 - 작업한 결과를 참석자들에게 데모하고 피드백 받기 스크럼 마스터 - 잘된 점, 아쉬웠던 점, 개선할 사항 등을 찾기위한 회고 진행

3. 스크럼 특징

• 투명성 : 프로젝트가 어떤 상태인지 어떤 문제점이 있는지 정확히 파악
• 타임박싱 : 스크럼을 진행하는데 들어가는 시간을 제한
• 커뮤니케이션
• 경험주의 모델 : 개개인의 경험 중요

뷰와 상호 작용하는 코드를 쉽게 ​​작성할 수 있는 기능입니다. 각 XML 레이아웃 파일의 바인딩 클래스가 자동으로 생성되고 이를 이용하여 해당 xml에 존재하는 id가 있는 모든 View를 직접 참조할 수 있습니다.

+대부분의 경우에 ViewBinding으로 findViewById 메서드를 대체할 수 있습니다.

View Binding 사용하는 방법

1) View Binding 설정

View Binding을 사용하기 위해서는 Android Studio 3.6 이상부터 사용이 가능합니다.

build.gradle (:app) 파일에 하단의 코드를 추가합니다.

• 방법 1 (Android Studio 4.0 미만 버전)

android {
    ...
    viewBinding {
        enabled = true
    }
}

• 방법 2 (Android Studio 4.0 이상 버전)

  android {
    ...
    buildFeatures {
            viewBinding true
    }
  }

+) 바인딩 클래스를 생성하고 싶지 않은 레이아웃의 경우 viewBindingIgnore를 true로 설정해주면 됩니다.

<LinearLayout
        ...
        tools:viewBindingIgnore="true" >
    ...
</LinearLayout>

2) Activity에서 View Binding 사용

1. View Binding을 사용하고자 하는 Activity에 바인딩 클래스 인스턴스를 선언합니다.

2. onCreate() 안에 inflate 메서드를 호출하여 Activity에서 사용할 바인딩 클래스 인스턴스를 생성합니다.

3. 바인딩 변수의 root View를 setContentView()에 전달하여 화면에서 활성화 된 View로 만듭니다.

private lateinit var binding : ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)
    }

이제 바인딩 클래스의 인스턴스를 사용하여 모든 뷰를 참조 할 수 있습니다.

binding.txt.text = "Hi"
binding.btn.setOnClickListener{
            ...
}