네트워크 / 보안
- 네트워크 전반적인 개념
velog.io/@tlatldms/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%A0%84%EA%B3%B5%EC%A7%80%EC%8B%9D
- OSI 7계층
# 1 Layer(물리적 계층) : 전기적 신호, 허브
# 2 Layer(데이터 링크 계층) : 프레임, 이더넷, L2 스위치
# 3 Layer(네트워크 계층) : 패킷, IP, ARP, ICMP, 라우터, L3 스위치
# 4 Layer(트랜스포트 계층) : 세그먼트, 포트 사용(TCP / UDP), L4 스위치
# 5 Layer(세션 계층) : 세션 유지, 복구 및 종료를 담당
# 6 Layer(표현 계층) : 데이터 인코딩 및 디코딩, 포맷 구분
# 7 Layer(어플리케이션 계층) : 데이터 혹은 메시지, 텔넷, HTTP, FTP
- 슬라이딩 윈도우
# Go-Back-N
# Selective
# 순서번호, ACK
# Time-out, 3 ACK Duplicated
- 혼잡제어
# 수신윈도우 : rwnd
# 혼잡윈도우 : cwnd
# 송신윈도우 : min(rwnd, cwnd) 사용
# AIMD(1씩 증가, 감소시 절반), Slow Start(지수 증가, 감소시 1)
# 타임아웃이 지나지 않아도 재전송하는 것을 빠른 재전송이라고 한다.
# ssthresh 넘을 시 1씩 증가
# TCP Tahoe : 3 ACK Duplicated, Timeout 시에 혼잡윈도우 사이즈 1, ssthresh 혼잡윈도우 크기의 1 / 2
# TCP Reno : 3 ACK Duplicated시 사이즈 1/2, TimeOut시에 사이즈 1, ACK Duplicated일 때만 ssthresh 혼잡윈도우 크기의 1 / 2
# 혼잡제어를 사용하면, 모든 호스트들이 균일하게 통신대역을 사용할 수 있다.
evan-moon.github.io/2019/11/26/tcp-congestion-control/
- HTTP 응답 코드
1xx : 정보(조건부) 응답
2xx : 성공
3xx : Ridirection Message Client는 요청을 마무리하기 위해 추가동작을 해야합니다.
4xx : Client 요청 오류. Client가 전송한 코드에 오류가 있음
5xx : 서버 오류.
- REST API
# 자원(RESOURCE) - URI
# 행위(Verb) - HTTP METHOD(POST, GET, PUT, DELETE)
# POST와 PUT은 모두 리소스를 생성할 수 있지만, POST는 매번 리소스를 생성하고, PUT은 리소스를 1회 생성 및 수정
# 표현(Representation)
# 유니폼 인터페이스 : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐 스타일
# 무상태성 : 작업을 위한 상태정보를 따로 저장 및 관리하지 않는다, 들어오는 요청만 단순히 처리
# 캐시 기능
# 자체 표현 구조 : REST API 메시지만 보고도 쉽게 이해 가능
# Client - Server 구조
# 계층형 구조 : 네트워크 기반의 중간매체를 사용 가능
# CRUD(Create, Read, Update, Delete)
- 패러티 비트(Parity Bit)
# 통신에서 오류를 색출하기 위한 비트
# 짝수 패러티(Even Parity) : 패러티 비트를 포함해서, 1의 개수가 짝수개
# 홀수 패러티(Odd Parity) : 패러티 비트를 포함해서, 1의 개수가 홀수개
- MSS와 MTU
MTU = 최대 크기의 Packet 혹은 Frame, 일반적으로 IP Header + TCP Header + Payload
IP MTU와 Ethernet MTU : 이더넷 MTU는 이더넷의 헤더를 제외한 이더넷 페이로드 부분만 의미하고, IP MTU는 아이피 헤더를 포함
MSS = Payload(MSS = MTU - IP Header - TCP Header)
MSS와 MTU는 영향을 받는다, 하위 계층의 크기에 따라서, 상위 계층의 크기는 무조건 영향을 받는다.
MTU 값이 크면, 여러 장비들을 거쳐서 단편화가 발생할 수도 있다(MTU가 작은 장비를 만날 경우)
MTU 값이 작으면, 보내야할 패킷의 수가 증가하기 때문에 느리다.
garimoo.github.io/study/2018/03/26/MSS_MTU.html
- TCP와 UDP
# TCP = 가상회선방식, Sliding Window
# UDP = 데이터그램방식
- 암호화 기법
# 개인키 암호화 : 대칭 암호화 기법, 관리 키의 수가 많음, 알고리즘이 단순
# 공개키 암호화 : 비대칭 암호화 기법, 관리 키의 수가 적음, 알고리즘이 복잡(RSA, DSA)
# 해쉬 : 입력 데이터를 고정된 길이의 값이나 키로 변환 - 세션
#
데이터베이스
- 데이터베이스 기초
# 외부스키마 : 사용자 관점의 스키마
# 개념스키마 : 전체적인 관점의 스키마
# 내부스키마 : 시스템 관점의 스키마
- 키
# 기본키 : 후보키 중에 선택된 키
# 후보키 : 최소성과 유일성을 만족하는 키
# 외래키 : 타 릴레이션의 기본키를 의미
# 대체키 : 기본키를 제외한 나머지 후보키
# 슈퍼키 : 유일성을 만족시키지만, 최소성을 만족시키지 못하는 키
# 최소성 : 모든 레코드들을 유일하게 식별하는데 꼭 필요한 속성만으로 구성되어 있어야한다.
# 유일성 : 키값으로 하나의 튜플만을 유일하게 식별할 수 있어야한다.
coding-factory.tistory.com/220
- 데이터베이스 언어란?
# DDL(데이터 정의 언어) : CREATE, DROP, ALTER
# DML(데이터 조작 언어) : 질의어
# DCL(데이터 제어 언어) : 권한, 보안, 무결성을 위해 존재
coding-factory.tistory.com/217?category=784883
- 데이터 무결성
# 무결성 : 데이터가 옳다는 것을 증명하는 성질
# 널 무결성 : 릴레이션의 특정 속성이 Null이 될 수 없는 규정
# 고유 무결성 : 특정 속성에 대해서, 값이 달라야 한다는 규정
# 참조 무결성 : 참조할 수 없는 외래키 값을 가질 수 없는 규정
# 도메인 무결성 : 특정 속성의 값이, 정의된 도메인에 속한 값이어야 한다는 규정
# 키 무결성 : 하나의 테이블에는 적어도 하나의 키가 존재해야 한다는 규정
- 트랜잭션(ACID)
# 트랜잭션 : 질의에 대한 하나의 단위, 병렬로 처리가 가능
# 원자성(Atomicity) : All or Nothing, rollback, savepoint
# 일관성(Consistency) : 트랜잭션이 성공적으로 완료되면 일관적인 DB상태를 유지하는 것을 말합니다. 어떤 외래키가 변경될 시에 trigger를 통해서 모든 데이터를 일관성있게 관리
# 고립성(Isolation) : 트랜잭션 수행시 다른 트랜잭션의 작업이 끼어들지 못하도록 보장하는 것을 말합니다, 2PL, lock, unlock
# 지속성(Durability) : 성공적으로 수행된 트랜잭션은 영원히 반영이 되는 것을 말합니다.(commit)
- 정규화 상세 설명
# 정규화의 목적은 중복데이터를 없애고, 삽입이상, 갱신이상, 삭제이상을 없애는 것
# 삽입이상 : 릴레이션에 데이터를 넣을 때, 어떤 속성이 null로 들어가는 경우
# 갱신이상 : 데이터를 갱신할 때, 다른 데이터들도 수정이 필요한 경우
# 삭제이상 : 데이터를 삭제했을 때, 중요한 정보가 사라지는 경우
# 예시 테이블(학번, 과목코드, 성적, 학부, 등록금)
# 1NF : 모든 속성들이 원자값을 가진다.
# 2NF : 부분 함수적 종속성이 없이 완전 함수적 종속성으로만 이루어져야 한다.
# 3NF : 기본키가 아닌 속성이, 기본키에 이행적 함수 종속이 되지 않아야 한다.
X는 기본키일때, X > Y, Y > Z면 X > Z가 되는 이행적 함수 종속 발생
# BCNF : 모든 결정자가 후보키 집합에 속해야 한다.
# 역정규화 : 정규화된 데이터 베이스에서 성능을 증가시키기 위한 방법, 데이터 베이스의 조회 성능을 증가시킨다, 하지만, 중복된 데이터로 인해서 쓰기 성능이 저하될 수 있다. - 인덱스
# 인덱스 사용 이유 : 모든 데이터를 조사하지 않고도, 인덱스 정보만으로 원하는 데이터를 찾을 수 있다. 인덱스는 키에 따른 필드 값을 갖고 있기 때문이다.
# 인덱스 자료구조 종료는 해쉬 테이블, B+트리, B-트리가 있다.
- 기본 쿼리
# SELECT : SELECT * FROM TABLE WHERE 조건
# INSERT : INSERT INTO 테이블명 VALUES ()
# DELETE : DELETE FROM TABLE WHERE 조건
# ORDER BY : 기본정렬 순서는 오름차순(ASC)이다, 내림차순은(DESC)
# GROUP BY : 원하는 데이터들을 그룹으로 나눌 수 있다, WHERE절에서는 GROUP BY를 위해 사용하는 그룹함수를 절대 사용 불가(HAVING을 사용)
# HAVING : 그룹에 대해서 조건 적용, GROUP BY의 조건(COUNT, MAX, SUM) 적용
- JOIN
# INNER JOIN : 두 테이블의 공통 요소로 결과를 리턴
# OUTER JOIN : LEFT, RIGHT가 존재
* LEFT OUTER JOIN : from table1 left outer join table2 on 조건, table1의 데이터를 모두 유지
* RIGHT OUTER JOIN : from table1 right outer join table2 on 조건, table2의 데이터를 모두 유지
* FULL OUTER JOIN : from table1 full outer join table2 on 조건, table1과 table2의 데이터를 모두 유지
# CROSS JOIN : ON이라는 특정 조건없이, table1과 table2의 모든 결합 상태를 보여주는 것
자바
- 객체지향 프로그래밍 특징
- OOP
- 객체들이 서로 유기적으로 동작하는 프로그래밍 이론
- 코드의 재사용성과 중복제거가 가장 큰 목적
- 추상화
- 목적과 관련이 없는 부분을 제외해서 필요한 부분을 포착하는 기법
- 객체의 공통된 속성들 중 필요한 부분을 포착해서 클래스로 정의하는 설계 기법
- 캡슐화
- 외부에 노출할 필요가 없는 정보들은 은닉 (정보은닉)
- 캡슐화는 외부와 내부를 구분, 은닉화는 내부의 정보를 숨기는 것
- 상속
- 상속 관계에 있는 두 클래스에 대해, 부모 클래스가 자손 클래스에게 속성을 물려주는 것
- 코드의 재사용이 목적
- 다형성
- 같은 형태이지만 다른 기능을 하는 것
- String.valueOf, Integer.valueOf
- 같은 메소드지만 호출하는 클래스에 따라서 다른 기능을 함
* 객체란?
객체(Object)란 물리적으로 존재하거나 추상적으로 생각할 수 있는 것 중에서 자신의 속성을 가지고 있고 다른것과 식별 가능한 것을 말합니다.
객체는 속성과 동작으로 구성되어 있다고 보면 되는데 자바에서는 이 속성과 동작을 각각 필드(field) 와 메소드(method) 라 부릅니다.
- 오버로딩과 오버라이딩
# 오버로딩 : 같은 이름의 메소드를 다양한 매개변수로 정의
# 오버라이딩 : 부모 클래스의 메소드를 재정의
- Wrapper class
자바의 자료형은 크게 기본 타입(primitive type)과 참조 타입(reference type)으로 나누어집니다. 대표적으로 기본 타입은 char, int, float, double, boolean 등이 있고 참조 타입은 class, interface 등이 있는데 프로그래밍을 하다 보면 기본 타입의 데이터를 객체로 표현해야 하는 경우가 종종 있습니다.
이럴 때에 기본 자료타입(primitive type)을 객체로 다루기 위해서 사용하는 클래스들을 래퍼 클래스(wrapper class)라고 합니다. 자바는 모든 기본타입(primitive type)은 값을 갖는 객체를 생성할 수 있습니다. 이런 객체를 포장 객체라고도 하는데 그 이유는 기본 타입의 값을 내부에 두고 포장하기 때문입니다. 래퍼 클래스로 감싸고 있는 기본 타입 값은 외부에서 변경할 수 없습니다. 만약 값을 변경하고 싶다면 새로운 포장 객체를 만들어야 합니다. - try/catch/finally
# try : try 내부에서 Exception이 발생하면 catch에서 처리할 수 있다.
# catch : 해당되는 Exception에 대해서 처리할 코드를 작성
# finally : 무조건 실행되는 코드, catch 실행 여부와 관계없이
- 제네릭
# ArrayList<T>에 들어가는 T를 의미한다.
# 제네릭을 선언하므로써, 다양한 형에 대해서 다룰 수 있게 한다.
coding-factory.tistory.com/573
- 추상클래스와 인터페이스
추상클래스와 인터페이스의 공통점은, 선언만 있고, 구현 내용은 없는 클래스이다. 인스턴스화 할 수 없다. 추상 클래스를 extends로 상속받은 자식들과 인터페이스를 implements한 자식들만 객체를 생성할 수 있다.
차이점은, 추상클래스는 단일상속, 인터페이스는 다중상속이다. 추상클래스의 목적은 상속을 통한 기능 확장이고, 인터페이스의 목적은 모든 클래스에 대해서 특정한 메소드가 반드시 존재하도록 강제하는 역할이라고 볼 수 있다. - 접근제어자
# public : 모든 접근을 허용
# protected : 같은 패키지(폴더)에 있는 객체와 상속관계의 객체들만 허용
# default : 같은 패키지(폴더)에만 허용
# private : 현재 객체내에서만 허용
- Call-by-value, Call-by-reference
# Call-by-value : 스택 영역에서 데이터 변경, 일시적 변경
# Call-by-reference : 힙 영역에서 데이터 변경, 영구 변경
wayhome25.github.io/cs/2017/04/11/cs-13/
- 안드로이드 실행환경 및 콜백
# 리눅스커널, 라이브러리, 어플리케이션 프레임워크, 어플리케이션
# 커널 : 컴퓨터 과학에서 커널은 컴퓨터의 운영 체제의 핵심이 되는 컴퓨터 프로그램의 하나로, 시스템의 모든 것을 완전히 통제한다. 운영 체제의 다른 부분 및 응용 프로그램 수행에 필요한 여러 가지 서비스를 제공한다.
# 프레임워크 : 컴퓨터 프로그래밍에서, 소프트웨어 프레임워크는 복잡한 문제를 해결하거나 서술하는 데 사용되는 기본 개념 구조이다. 간단히 뼈대, 골조, 프레임워크라고도 한다. 이렇게 매우 폭넓은 정의는 이 용어를 버즈워드로서, 특히 소프트웨어 환경에서 사용할 수 있게 만들어 준다.
# 콜백 : 어떤 이벤트에 의해 자동으로 호출되어지는 함수
- 안드로이드 4대 구성요소
액티비티 : 어플리케이션은 최소의 하나의 액티비티를 가짐, 사용자에게 보여지는 화면
서비스 : UI 스레드에서 동작, 별도의 스레드 생성 가능, 백그라운드 서비스
브로드캐스트 리시버 : 안드로이드 OS로부터 발생하는 각종 이벤트와 정보를 받아와 핸들링
콘텐트 프로바이더 : 어플리케이션간에 데이터 송수신(용량이 큰 사진, 파일)
# Service : 짧은 작업에 적절, 모든 서비스의 기본 클래스로, 클래스를 확장할 때는 서비스가 모든 작업을 완료할 수 있는 새 스레드를 생성하는 것이 중요합니다. 서비스는 기본적으로 애플리케이션의 기본 스레드를 사용하기 때문에 애플리케이션이 실행 중인 액티비티의 성능을 저하시킬 수 있습니다.
# IntentService : 긴 작업에 적절, Service 의 하위 클래스로, 작업자 스레드를 사용하여 모든 시작 요청을 처리하되 한 번에 하나씩 처리합니다. 서비스가 여러 개의 요청을 동시에 처리하지 않아도 되는 경우에는 최선의 옵션입니다. onHandleIntent()를 구현합니다. 이는 각 시작 요청에 대해 인텐트를 수신해서 백그라운드 작업을 완료하도록 합니다. 일반적으로, 노래를 트는건 IntentService에 해당한다. 메인 스레드가 아닌 새로운 워커 스레드를 만든다.
# ContentProvider : 어플리케이션 사이에 데이터를 공유할 수 있게 하는 통로
# ContentResolver : 어떤 어플리케이션 내부에서 결과에 관한 브릿지 역할
- 안드로이드 프로세스와 스레드
# 메인스레드 : 이벤트 생성 및 처리, 다양한 뷰에 관여, 메인스레드
# 워커스레드 : UI 스레드를 블록하지 않고 동작, AsyncTask을 사용할 수 있음
# 핸들러 : 스레드간 통신 방법(메시지, 루퍼, 메시지큐, 핸들러)
anitoy.pe.kr/android-process-thread-concept/
# 메인 스레드 : UI 관련 작업은 모두 메인 스레드에서 발생해야함
# 워커 스레드 : UI 스레드를 블록하지 않고, 새로운 스레드에서 작업이 진행되도록 함
medium.com/@joongwon/android-service%EC%99%80-thread%EC%9D%98-%EC%B0%A8%EC%9D%B4-a9175016450
# 서비스와 스레드의 차이
# 서비스 : 프로세스(타 어플리케이션)간 통신 가능, 백그라운드 작업에 적절
# 스레드 : 프로세스 내부 통신, 포그라운드 작업에 적절, 핸들러로 통신
안드로이드 생명주기
# onCreate : 이 메서드는 savedInstanceState 매개변수를 수신하는데, 이는 액티비티의 이전 저장 상태가 포함된
Bundle객체입니다. 이번에 처음 생성된 액티비티인 경우Bundle객체의 값은 null이다. 가로, 세로 화면전환시 콜백(onDestroy까지 진행된 후)이 발생하는데, 이 때 savedInstanceState가 사용될 것이다. onPause나 onStop의 상태에서 메모리가 부족할 때, 사용자가 해당 액티비티로 이동한다면 onCreate 콜백
# onStart : 액티비티가 사용자에게 표시되고, 앱은 액티비티가 포그라운드에 보내 상호작용할 수 있도록 준비한다.
# onResume : 액티비티가 재개됨 상태에 들어가면 포그라운드에 표시되고 시스템이onResume()콜백을 호출합니다. 이 상태에 들어갔을 때 앱이 사용자와 상호작용합니다. 어떤 이벤트가 발생하여 앱에서 포커스가 떠날 때까지 앱이 이 상태에 머무릅니다. 예를 들어 전화가 오거나, 사용자가 다른 액티비티로 이동하거나, 기기 화면이 꺼지는 이벤트가 이에 해당합니다.
# onPause : 시스템은 사용자가 활동을 떠나는 것을 나타내는 첫 번째 신호로 이 메서드를 호출합니다(하지만 해당 활동이 항상 소멸되는 것은 아님). 활동이 포그라운드에 있지 않게 되었다는 것을 나타냅니다(다만 사용자가 멀티 윈도우 모드에 있을 경우에는 여전히 표시 될 수도 있음). onPause() 메서드를 사용하여 Activity가 일시중지됨 상태일 때 계속 실행(또는 적절히 계속 실행)되어서는 안 되지만 잠시 후 다시 시작할 작업을 일시중지하거나 조정합니다. 활동이 이 상태에 들어가는 이유는 여러 가지가 있습니다.
onPause()는 아주 잠깐 실행되므로 저장 작업을 실행하기에는 시간이 부족할 수 있습니다. 그러므로 onPause()를 사용하여 애플리케이션 또는 사용자 데이터를 저장하거나, 네트워크 호출을 하거나, 데이터베이스 트랜잭션을 실행해서는 안 됩니다. 이러한 작업은 메서드 실행이 끝나기 전에 완료되지 못할 수도 있습니다. 그 대신, 부하가 큰 종료 작업은 onStop() 상태일 때 실행해야 합니다. onStop() 상태 동안 실행할 적절한 작업에 관한 자세한 내용은 onStop()을 참조하세요
- onResume() 섹션에서 설명하였듯이, 일부 이벤트가 앱 실행을 방해합니다. 이것이 가장 일반적인 사례입니다.
- Android 7.0(API 수준 24) 이상에서는 여러 앱이 멀티 윈도우 모드에서 실행됩니다. 언제든지 그중 하나의 앱(창)만 포커스를 가질 수 있기 때문에 시스템이 그 외에 모든 다른 앱을 일시중지시킵니다.
- 새로운 반투명 활동(예: 대화상자)이 열립니다. 활동이 여전히 부분적으로 보이지만 포커스 상태가 아닌 경우에는 일시중지됨 상태로 유지됩니다.
# onStop : 활동이 사용자에게 더 이상 표시되지 않으면 중단됨 상태에 들어가고, 시스템은 onStop() 콜백을 호출합니다. 이는 예를 들어 새로 시작된 활동이 화면 전체를 차지할 경우에 적용됩니다. 시스템은 활동의 실행이 완료되어 종료될 시점에 onStop()을 호출할 수도 있습니다. onStop에서 다시 액티비티로 이동될 때, onRestart를 통해서 onStart로 이동.
또한 onStop()을 사용하여 CPU를 비교적 많이 소모하는 종료 작업을 실행해야 합니다. 예를 들어 정보를 데이터베이스에 저장할 적절한 시기를 찾지 못했다면 onStop() 상태일 때 저장할 수 있습니다. 다음 예시는 초안 내용을 영구 저장소에 저장하는 onStop()을 구현한 것입니다.
# onDestroy : 활동이 소멸되기 전에 호출됩니다. 시스템은 다음 중 하나에 해당할 때 이 콜백을 호출합니다.
- (사용자가 활동을 완전히 닫거나 활동에서 finish()가 호출되어) 활동이 종료되는 경우
- 구성 변경(예: 기기 회전 또는 멀티 윈도우 모드)으로 인해 시스템이 일시적으로 활동을 소멸시키는 경우
활동이 소멸됨 상태로 전환하면 이 활동의 수명 주기와 연결된 모든 수명 주기 인식 구성요소는 ON_DESTROY 이벤트를 수신합니다. 여기서 수명 주기 구성요소는 활동이 소멸되기 전에 필요한 것을 정리할 수 있습니다.
developer.android.com/guide/components/activities/activity-lifecycle?hl=ko
- 안드로이드 Context
# 애플리케이션 컨텍스트 : 애플리케이션의 라이플 사이클과 연결, 잘못 사용시 GC에 의해서 액티비티가 수집되지 않아 메모리 누수 발생 가능
# 액티비티 컨텍스트 : 액티비티의 라이프 사이클과 연결, 애플리케이션 컨텍스트가 항상 적용되는 것은 아님(GUI)
shinjekim.github.io/android/2019/11/01/Android-context%EB%9E%80/
- 안드로이드 Manifest, gradle
# Manifest : 안드로이드 컴포넌트, 권한 설정(퍼미션), 앱이 필요로하는 소프트웨어 혹은 하드웨어 특징 명시
# gradle : 안드로이드 스튜디오는 IDE이고, gradle이 빌드를 담당한다.
- 안드로이드 프래그먼트
# 프래그먼트 : 액티비티 1개당 여러개 존재 가능
# 액티비티에서 프래그먼트 통신 : 프래그먼트 매니저에서 findViewById 이용, 레이아웃 미존재시 Tag 사용
# 프래그먼트에서 액티비티와 통신 : getActivity() 메소드 사용
# 프래그먼트간 통신 : 프래그먼트 간 통신에 권장되는 방법은 공유된 ViewModel 객체를 만드는 것입니다. 두 프래그먼트는 포함된 활동을 통해 ViewModel에 액세스할 수 있습니다. 프래그먼트는 ViewModel 내 데이터를 업데이트할 수 있으며 LiveData를 통해 데이터가 노출되면 ViewModel의 LiveData를 관찰하고 있는 한 새로운 상태가 다른 프래그먼트로 푸시됩니다. 이와 같은 통신의 구현 방법을 확인하려면 ViewModel 가이드의 '프래그먼트 간 데이터 공유' 섹션을 읽어보세요.
- 안드로이드 서비스 바인딩
# 언바인딩 서비스는 계속해서 유지, 액티비티 생명주기와 관련없음
# 바인딩 서비스는, 호출한 액티비티가 클라이언트 서비스가 서버 역할을 함
# 바인딩은 액티비티의 생명주기와 동일함, 액티비티가 종료되면 서비스 종료
# IBinder가 서비스에서 인터페이스 역할을 함
- 안드로이드 인플레이터
# setContentView로 전체 레이아웃 구성을 조정할 수 있다.
# 이후에 특정 View를 XML 파일을 inflate하고 싶을 때, 안드로이드 인플레이터를 사용
- 안드로이드 빌드과정
# 안드로이드 스튜디오 -> 클래스(DEX로 변환), 리소스(바이너리로 변환) -> Gradle에서 빌드(클래스, 리소스, 매니페스트) -> jarsigner에서 apk 파일 생성 -> adb(Android Debug Bridge)에서 install 및 실행
- 안드로이드 인텐트
# 인텐트 : 액티비티 시작, 서비스 시작, 브로드캐스트 전송
# 명시적 인텐트 : 인텐트를 충족하는 애플리케이션이 무엇인지 지정합니다. 이를 위해 대상 앱의 패키지 이름 또는 완전히 자격을 갖춘 구성 요소 클래스 이름을 제공합니다. 명시적 인텐트는 일반적으로 앱 안에서 구성 요소를 시작할 때 씁니다. 시작하고자 하는 액티비티 또는 서비스의 클래스 이름을 알고 있기 때문입니다. 예를 들어, 사용자 작업에 응답하여 새로운 액티비티를 시작하거나 백그라운드에서 파일을 다운로드하기 위해 서비스를 시작하는 것 등이 여기에 해당됩니다.
# 암시적 인텐트 : 특정 구성 요소의 이름을 대지 않지만, 그 대신 수행할 일반적인 작업을 선언하여 다른 앱의 구성 요소가 이를 처리할 수 있도록 해줍니다. 예를 들어 사용자에게 지도에 있는 한 위치를 표시하고자 하는 경우, 암시적 인텐트를 사용하여 해당 기능을 갖춘 다른 앱이 지정된 위치를 지도에 표시하도록 요청할 수 있습니다. 보안성이 낮다.
# 펜딩 인텐트 : 특정한 이벤트(Notification)에 대해서 인텐트를 실행할 수 있도록 하는 것
developer.android.com/guide/components/intents-filters?hl=ko
- 안드로이드 리사이클러뷰
# 뷰홀더 : 각 뷰의 내용을 업데이트 하기 위해 findViewById 를 매번 호출하면 성능 저하가 발생하므로, ItemView의 각 요소를 바로 엑세스 할 수 있도록 저장해두고 사용하기 위한 객체입니다
- GC(Garbage Collector)
# 힙 메모리는 Young(eden, survivor1, survivor2), Old, Permenant(클래스, 메소드)로 구성
# Minor GC는 Young에 관여, Major GC는 Old, Permenant에 관여.
# 일정 age가 지나면, Old 영역으로 들어간다
# reachablity를 조정을 통해 GC에 관여할 수 있다.(Strong, weak, soft, phantom)
# survivor이 2개인 이유 : GC로 메모리를 할당 해제하면서, 조각들이 발생할 수 있기 때문에 새로운 서바이버 영역으로 모두 몰아넣어서 조각들을 제거시킨다. 연속적인 공간을 확보하기 위해서.
# generation을 나눈 이유 : 작은 영역들로 나누면서, GC의 오버헤드를 줄이기 위해서
# Stop The World : GC가 발생하면 GC를 실행하는 쓰레드 외에 모든 쓰레드들이 정지한다. Stop The World 시간을 줄이는 것을 GC 튜닝이라고 한다.
# 가비지 컬렉터 두 가지 가정
1. 대부분의 객체는 금방 접근 불가능 상태(unreachable)가 된다.
2. 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.
# 가비지 컬렉터 종류(Old GC를 처리하는 방식에 따라 분류)
- Serial Collector : 싱글 스레드로 성능 한계 존재(Mark - Sweep - Compaction)
- Parallel Collector : 멀티 스레드로 소요 시간을 감소시켜 성능 향상, CMS는 Stop The World 단축이 목적, Parallel 처리량 증가가 목적
- CMS Collector(Concurrent Mask And Sweep) : 백그라운드에서 동작하여 Stop The World를 최소화, 응답속도가 빠를 필요가 있는 상황에서 사용, 백그라운드에서 동작하여 CPU 사용량이 증가하고, Compaction 과정이 자동으로 제공되지 않아 메모리 파편화가 발생, 메모리 파편화 해결을 위한 Compaction 과정이 Stop The World가 길어지게 만드는 문제 발생
- G1 Collector : Region으로 영역을 나누며 Young과 Old 모두 될 수 있다, GC가 Region 단위로 발생
- 자바 Immutable
String, Boolean, Integer, Float, Long 등등이 있습니다. 여기서 주의할 점은 변경불가라는 것은 heap 영역에서의 변경불가라는 뜻입니다. String a="a"; a="b"; 와 같이 재할당은 가능합니다. 이는 a가 reference하고 있는 heap 영역의 객체가 바뀌는 것(new)이지 heap영역에 있는 값이 바뀌는 것이 아닙니다.
- 싱글톤 패턴
# 필요성 : Singleton pattern(싱글턴 패턴)이란 애플리케이션에서 인스턴스를 하나만 만들어 사용하기 위한 패턴이다. 커넥션 풀, 스레드 풀, 디바이스 설정 객체 등의 경우, 인스턴스를 여러 개 만들게 되면 자원을 낭비하게 되거나 버그를 발생시킬 수 있으므로 오직 하나만 생성하고 그 인스턴스를 사용하도록 하는 것이 이 패턴의 목적이다.
github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/DesignPattern
- 스택과 힙
# 프로그램 세그먼트
1. 코드 세그먼트 : 컴파일된 프로그램이 저장되는 영역, 일반적으로 read-only 속성이다.
2. 데이터 세그먼트 : 전역 변수 및 정적 변수가 저장되는 영역
3. 힙 세그먼트 : 동적으로 할당된 변수가 할당되는 영역
4. 스택 세그먼트 : 함수 매개 변수, 지역 변수 및 기타 함수 관련 정보가 저장되는 영역
- SOLID 원칙(OOP)
- SRP(Single Responsibility Principle) : 단일 책임 원칙
클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유이어야 한다. - OCP(Open-Closed Principle) : 개방-폐쇄 원칙
확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다. - LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. - ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다. - DIP(Dependency Inversion Principle) : 의존 역전 원칙
고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
defacto-standard.tistory.com/113
- static과 final
# static : 객체가 생성되기 이전에 이미 할당, 스태틱 영역, GC가 관리 X, 데이터 값 공유
# final : 값이 불변함, static final과 동일
coding-factory.tistory.com/524
운영체제
- 가상메모리
RAM이 충분하지 않기 때문에, RAM는 프로세스의 핵심 정보들만 올리고 나머지 정보들은 보조기억장치(디스크, SSD)에 올려두는 방식을 가상메모리라고 한다. CPU에서 가상 주소로 요청을 하면, MMU에서 물리 메모리(RAM)를 확인한다, 물리 메모리에 있을 시, 해당 명령어 및 데이터를 넘겨준다. 없을 시, 페이징 기법이나 세그먼테이션 기법을 통해서 물리 메모리에 명령어 및 데이터를 교체한다. 교체기법은 다양하다.
FIFO – 선출선입
LRU – 가장 오래 사용되지 않은 페이지 교체
최적은, 앞으로 오래 사용되지 않을 페이지를 교체하는 것인다. 실제로 예상하는 것이 불가.
- 메모리 할당 알고리즘
# Best-fit : 가장 적당한 사이즈에 메모리 할당
# First-fit : 첫번째로 확인되는 할당 가능 메모리에 할당(빠른 할당)
# Worst-fit : 가장 큰 사이즈에 메모리 할당
# 어떤 방법이든 메모리의 hole은 발생 가능
- 교착상태
# 교착상태 : 교착상태(Dead Lock)은 상호 배제에 의해 나타나는 문제점으로, 둘 이상의 프로세스들이 자원을 점유한 상태에서 서로 다른 프로세스가 점유하고 있는 자원을 요구하며 무한정 기다리는 현상
# 교착상태 발생조건
# 1. 상호배제 : 한번에 한개의 프로세스만이 공유 자원을 사용할 수 있어야 합니다.
# 2. 점유와 대기 : 최소한 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용되고 있는 자원을 추가로 점유하기 위해 대기하는 프로세스가 있어야 합니다.
# 3. 비선점 : 다른 프로세스가 사용하는 자원을 강제로 뺏을 수 없다.
# 4. 환형대기 : 프로세스가 자원을 요구하는 것이 원형을 이루고 있는 상태
coding-factory.tistory.com/311
- 캐시사상기법 및 캐시 지역성
# 직접사상 : 메모리 블록들이 지정된 캐시 라인 적재
# 연관 사상: 메모리 블록이 어떤 캐시 라인으로도 적재
# 집합 연관 사상: 직접 사상과 연관 사상의 조합
# 캐시의 타당함 : 지역성
1. 시간지역성 : 최근에 참조된 주소가 곧 다시 참조되는 특성
2. 공간지역성 : 최근에 참조된 주소가 또 다시 방문되는 특성(같은 공간)
blog.skby.net/%EC%BA%90%EC%8B%9C-%EC%82%AC%EC%83%81mapping-%EA%B8%B0%EB%B2%95/
- 페이징과 세그먼테이션
# 페이징 : 고정된 크기로 분할, 페이지 경계와 일치하지 않는 크기의 메모리를 요구하게 되면, 전부 사용되지 않고 남아버리는 내부 단편화 발생
# 세그먼테이션 : 고정된 크기의 블록이 아닌, 서로 다른 크기의 논리적 단위인 세그먼트로 분할, 서로 다른 크기의 세그먼트들이 메모리에 적재되고 제거되는 일이 반복되면 자유 공간들이 많은 수의 작은 조각들로 나누어져 못 쓰게 될 수 있다, 외부 단편화 발생
jupiny.com/2017/03/28/paging-segmentation/
- 프로세스와 스레드
# 프로세스 : Code, Data, Stack, Heap과 같은 독립된 메모리 영역을 할당, 다른 프로세스의 변수나 자료 구조에 접근 불가능, 접근하기 위해서는 IPC(파이프, 파일, 소켓) 등을 이용해 통신이 필요
# 스레드 : 프로세스 내에서 실행되는 여러 흐름의 단위, 스레드는 Stack만 따로 할당받고 Code, Data, Heap 영역은 공유
# Thread Safe : 여러 스레드가 어떤 데이터에 동시에 접근을 할 수 있어도, 프로그램의 실행 결과는 일정함을 보장
# Re-entrancy : 어떤 함수가 한 스레드에 의해 호출되어 실행될 때, 다른 스레드가 동일한 함수를 호출하더라도 실행 결과의 correctness가 보장
# Thread-local Storage : 공유 자원을 줄이고, 특정 스레드에서만 접근 가능한 저장 공간을 생성
# Mutual Exclusion : 공유 자원을 사용할 시에, 세마포어 등을 이용해서 상호 배제 보장
# Atomic Operations : 특정 스레드가 실행중인 과정을 다른 스레드가 접근할 수 없다.
- CPU 스케줄링
# 고수준 스케줄링 : 시스템 전체 작업 수를 조정
# 중간수준 스케줄링 : 활성화된 프로세스의 수를 조정
# 저수준 스케줄링 : 어떤 프로세스에 CPU를 할당할지 결정
- 동기와 비동기
# 동기 : 요청이 들어온 순서에 맞게 하나씩 처리하는 방식이다. 순서에 맞춰 진행되는 장점이 있지만, 여러 가지 요청을 동시에 처리할 수 없다.
# 비동기 : 하나의 요청에 따른 응답을 즉시 처리하지 않아도, 그 대기 시간동안 또 다른 요청에 대해 처리 가능한 방식이다. 여러 개의 요청을 동시에 처리할 수 있는 장점이 있지만 동기 방식보다 속도가 떨어질 수도 있다.
- 리틀엔디안 vs 빅엔디안
# 빅엔디안 : 사람이 숫자를 읽는 방식과 동일
# 리틀엔디안 : 사람과 반대
- 뮤텍스
# 크리티컬 세션 접근에 필요(공유 영역)
# lock(임계 구역에 들어갈 권한 획득), unlock(권한 해제)
# 뮤텍스와 세마포어의 차이 : 뮤텍스는 락을 걸은 쓰레드만이 락을 해제할 수 있다, 세마포어는 Signaling을 통해서, 락을 걸지 않은 쓰레드도 signal을 이용해 락을 해제할 수 있음. 세마포어의 카운터를 1로 설정하면 뮤텍스처럼 활용할 수 있다.
# 세마포어를 뮤텍스처럼 사용할 수 있지만, 뮤텍스는 절대 세마포어가 될 수 없다. - 버퍼링
버퍼를 사용하면, 어떤 데이터를 바로 처리하는 것이 아니라 버퍼를 채웠을 때 처리하게 된다. 버퍼링의 장점은 다른 흐름을 방해하지 않아서, 처리 속도를 향상시킬 수 있다.
알고리즘
- 정렬
선택소트 = 배열에서 최소값을 찾아서 앞에서부터 채워나가는 정렬, 팬케이크 뒤집기 문제 적용 가능
퀵소트 = 파티션 후, 피벗을 기준으로 정렬함수를 재귀적으로 호출한다(왼쪽, 오른쪽). 가장 왼쪽에 원소를, 피벗으로 삼고 왼쪽에는 피벗보다 작은 수가 오도록, 오른쪽에는 피벗보다 큰 수가 오도록 한다. 최종적으로 왼쪽에서 오는 인덱스와 오른쪽에서 오는 인덱스가 엇갈렸을때, 오른쪽 인덱스가 가리키는 수와 피벗을 바꾼다. 퀵소트 최악의 경우는 반으로 나눠지지 못하고 정렬된 상태일 때, 최악의 시간복잡도(n^2)를 가지게 된다.
버블소트 = 인접한 수끼리 계속 자리를 교환하면서, 맨 마지막 자리로 이동하는 모습이 물속에서 물위로 올라오는 물방울 모양과 같다고 해서 버블소트
머지소트 = 배열을 반으로 나눠 재귀적으로 호출하여, 크기가 1이 될 떄까지 분할한 후에, 백트래킹으로 합친다.
힙소트 = 배열로 표시할 수 있다. 자식 노드 / 2 = 부모노드이다. 최대 힙 트리를 만든다, 삽입시에 마지막에 노드를 삽입하여 부모와 비교해서 자리를 변경한다. 삭제 시에, 루트 노드를 삭제하고, 마지막 노드를 루트로 이동시키고 적절한 자리를 찾도록 한다.
삽입정렬 = 자료 배열의 모든 요소를 앞에서부터 차례대로 이미 정렬된 배열 부분과 비교하여, 자신의 위치를 찾아 삽입함으로써 정렬을 완성
- 다익스트라(우선순위 큐, 시간복잡도 = O(ElogV, V^2))
# 음수 가중치 사용불가(사이클 생성 가능)
# ElogV도 많이 사용하지만, V^2의 코드도 필요할 떄가 있다.
# O(V^2) : 배열을 이용해서 코드 작성, 가장 거리가 가까운 노드를 구해주는 함수 필요, dist[]를 시작점을 제외하고 모두 큰 값으로 초기화. 가장 가까운 노드를 하나씩 구해가면서, 최소 거리를 구한다. 매 순간의 가장 가까운 노드들보다 더 가깝게 해당 노드로 가는 방법은 절대없다. (타당성 증명)
# O(ElogV) : Min Heap Tree를 이용해 구현, 가장 거리가 가까운 노드를 Min Heap Tree에서 자동으로 구해준다,
- 플로이드-워셜(시간복잡도 = O(V^3))
# 음수가중치 사용가능
# 다이나믹 프로그래밍, 노드 i와 j가 있다고 한다면, k번째 노드를 포함해서 최단 거리를 구하는 것은,
dp[i][j[k] = Math.min(dp[i][j][k - 1], dp[i][k][k - 1] + dp[k][j][k - 1])으로 볼 수 있다. for문을 돌리는 것은, 다이나믹 프로그래밍에 해당된다.
- 벨만포드(시간복잡도 = O(VE))
# Outer Loop가 N - 1인 이유 : 벨만포드는 N - 1번 모든 Edge에 대해서 검사를 하도록 되어 있다. 시작점에서 어떤 점과 연결되어 있을 때, 어떤 점을 포함해서 최대 연결될 수 있는 점들은 N - 1개이다. 벨만 포드는 N번째에도 값이 갱신된다면, 음수 사이클이 있는 것으로 판명한다.
- 최소신장트리(크루스칼, 프림)
# 모든 정점(N개)들을 최소의 간선(N - 1개)으로 연결하고 싶은 경우
gmlwjd9405.github.io/2018/08/28/algorithm-mst.html
- 크루스칼 알고리즘(코드)
# 최단 간선을 위주로 선택
# 사이클 형성 확인을 위해서 Union-Find를 사용한다.|
# O(ElogE) : 모든 간선들을 Min Heap Tree에 넣고, 사이클이 형성되지 않도록 최단 경로를 만들면 된다.
- 프림 알고리즘(코드)
# 사이클이 형성되지 않는다
# 정점 위주 선택
# 시간복잡도(우선순위큐) O(VlogV) + O(ElogV) = O(ElogV)
* 큐가 항상 V 사이즈를 가져서, logV가 되는 것은 아니다. 현재 선택될 노드가 K번째라고 할때 큐 사이즈는, 최대 K * V을 가질 수 있다, log(KV)은 logV이므로 일반적으로 logV라고 얘기한다.
# 시간복잡도(배열사용) O(V^2) + O(E) = O(V^2)
# 배열 사용 : 루프 N - 1번을 돌면서, 방문되지 않으며 거리가 가장 짧은 노드를 찾고 추가, 추가된 노드에서 연결된 간선들을 확인해서 최소값 갱신
- 최대공약수와 최소공배수 구하기
# a, b가 존재할 때(a > b)
# r = a % b
# gcd(a, b) = gcd(b, r)
# 최소 공배수는 a * b / gcd(a, b)가 된다.
# 최소 공배수는 두 수에 1부터 곱하기 시작했을 때 최초로 같은 수를 의미한다.
# 10 = 2 * 5
# 12 = 2^2 * 3
# 10과 12의 최소 공배수는 두 수를 곱한 다음에, 최대 공약수로 나눠주면 된다.
- 트리 방문 알고리즘
# 각 방문 알고리즘에 Pre, Post, In은 루트 노드 방문을 의미한다.
# 각 방문은 재귀적으로 구성이 되어 있다.
# PreOrder : 루트 노드 -> 왼쪽 서브트리 -> 오른쪽 서브트리
# InOrder : 왼쪽 서브트리 -> 루트 노드 -> 오른쪽 서브트리
# PostOrder : 왼쪽 서브트리 -> 오른쪽 서브트리 -> 루트 노드
# 이진 탐색 트리가 있을 때, 가장 큰 노드부터 순차적으로 방문하고 싶다면 Reverse InOrder 방식으로 코드를 구현하면 된다.
자료구조
- Trie
# 문자열에 속한 하나의 문자씩 돌아가면서, 트리를 따라서 존재 여부를 확인할 수 있음
# 문자열의 길이만큼 탐색으로 존재 여부 확인 가능
# TrieNode : HashMap<Character, TrieNode> childern, Boolean isEndOfWord
# 탐색 : 문자를 하나씩 탐색하면서, 끝 문자에서 IsEndOfWord가 True여야 한다. 도중에 TrieNode가 없다면, 중지하면 된다.
# 삽입 : 문자를 하나씩 삽입하면서, 트라이 노드가 존재하지 않는다면 노드를 새로 생성해주면서, 마지막 문자에서 isEndOfWord를 True로 만들어준다.
# 삭제 : 삭제 예정인 문자열은, 다른 문자열과 연관이 있으면 안된다. 마지막 문자열은 leaf 노드이면서, 자식 노드가 없어야 한다. isEndOfWord를 false로 바꿔주면 된다.
real-012.tistory.com/manage/newpost/164?type=post&returnURL=https%3A%2F%2Freal-012.tistory.com%2F164
- 레드블랙트리
# 균형잡힌 이진 탐색 트리(logN)
# 레드블랙트리 조건
1. 각 노드는 레드 OR 블랙
2. 루트 노드는 블랙
3. 모든 리프 노드는 블랙
4. 레드 노드의 자식은 블랙
5. 모든 노드에 대해서, 리프 노드까지 동일한 블랙 노드 존재
# 항상 O(logN)의 탐색을 가짐을 증명, h를 트리의 높이라고 하고 bh를 임의의 블랙 노드들의 높이라고 하면,
bh >= h/2이다.
# 전체 노드의 개수를 N이라고 하면, N >= 2^bh - 1 >= 2^h/2 - 1을 만족한다. 양변에 로그를 취하면,
h <= 2log(N + 1)이 나오게 된다. 따라서, 탐색의 연산을 O(logN)에 수행할 수 있다.
# 삭제 시, Extra-black을 제거하고 기준 5를 만족시키는것이 목표
# Left-rotate, Right-rotate
- 해시테이블
# 키, 해쉬값, 해쉬함수, 저장소(버킷)
# 삽입, 삭제, 탐색의 시간복잡도는 O(1), 해쉬충돌 발생 시 최악의 경우 O(n), n은 데이터의 개수
# 해쉬충돌 : 다른 두 키가 같은 해쉬값을 가질 때, 비둘기집의 원리
# 해쉬충돌 해결법
1. Chaining : 외부 공간에 데이트를 연결 및 저장
2. 개방주소법 : 해쉬함수값이 비어있는 공간을 찾아가는 방법
# Load factor = 데이터의 개수 / 해쉬값의 개수
- 이진탐색트리
# 이진 탐색 트리는 노드들을 거쳐 가면서, 해당 위치에서 삽입될 수 있는 노드의 최소와 최대가 결정된다.
# 삽입, 삭제 모두 탐색이 베이스
# 삽입 시에, 탐색하고, 리프노드에 추가
# 삭제 과정
1. 자식 노드가 없는 경우, 단순 삭제
2. 자식 노드가 한개인 경우, 해당 노드의 자식 노드와 부모 노드를 연결
3. 자식 노드가 두개인 경우, 왼쪽 서브 트리에서 가장 오른쪽에 있는 값 혹은 오른쪽 서브 트리에서 가장 왼쪽에 있는 값을 가져온다.
- B+Tree, B-Tree
# B-Tree : 이터널 노드에 데이터를 포함시킨다, 노드를 탐색할 때 리프노드까지 도달하지 않고 탐색이 가능하다.
# B+Tree : B-Tree와 다르게 모든 데이터가 리프 노드에 존재, 항상 O(logN)의 시간이 걸린다. 반면에 B-Tree는 도중에 찾는 노드가 있다면, 중지할 수 있다. 이터널 노드에 데이터에 관련된 노드가 없으므로, 더 많은 포인터들을 포함시킬 수 있다. 즉, 같은 데이터가 주어졌을 때, B+Tree는 높이가 더 낮게 만들어진다.
개발방법론
- TDD
테스트를 먼저 만들고, 테스트를 통과하기 위해서 짜는 것
일반적으론 코딩이 끝나고 테스트 케이스를 적용하지만, 테스트 케이스 통과를 우선적용
- 개발방법론
# 스프린트 : 단기 기간동안 목표 수행
# 스크럼 : 스프린트 리뷰와 회고를 하는 과정
# 백로그 : 결정된 우선순위를 기반으로 스프린트 기간동안 해야할 리스트
- 리팩토링
# 코드의 가독성 및 유지보수성을 증가시킴
# Bad Smell : 중복된 코드, 메소드가 지나치게 길 때, 클래스가 클 때, 클래스의 역할 부족, 임시 필드, 메시지 체인, 클래스간 미들맨이 존재할 때, 클래스가 지나치게 친밀할 때
- 결합도와 응집도
m.blog.naver.com/gluestuck/221899977072
- 소프트웨어 생명주기
- 소프트웨어 생명주기 : 소프트웨어 개발을 하기 위한 정의, 운용, 유지보수 등의 각 과정을 단계별로 나눈 것
- 폭포수 모형 : 선형 순차적 모형, 이전 단계로 돌아갈 수 없음
- 개발 단계 : 타당성 검토 - 계획 - 요구분석 - 설계 - 구현 - 검사 - 유지보수
- 장점 : 모형의 적용 경험과 성공 사례, 단계별 산출물이 정확해 기준이 확실
- 단점 : 새로운 요구 적용 어려움, 요구 사항의 명확성 필요, 단계 이동의 불확실성
- 프로로타입 모형 : 사용자의 요구사항을 정확히 파악하기 위해 견본품을 만들어 최종 결과물을 예측
- 개발 단계 : 요구 수집 - 빠른 설계 - 프로토타입 구축 - 고객평가 - 프로토타입 조정 - 구현
- 장점 : 요구 사항 반영, 변경 용이, 공동의 참조 모델 제공
- 단점 : 프로토타입과 결과물의 차이 발생, 프로토타입의 비효율성 발생 가능
- 나선형 모형 : 폭포수 + 프로토타입의 장점에 위험 분석 기능을 추가한 모형
- 개념 : 나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 점진적으로 순회
- 대규모 개발에 적합
- 개발 단계 : 계획 - 위험 분석 - 개발 - 고객 평가
- 장점 : 대규모 시스템에 적합, 추가된 요구사항 반영 가능, 유지보수 과정 불필요
- 단점 : 위험성 평가에 의존, 최신 기법이라 사례 부족
- 애자일 모형 : 고객의 요구사항에 유연한 대응이 가능, 고객과의 소통에 초점
- 짧은 개발 주기를 반복하여 도출된 결과에 대해 고객의 평가를 적극적 수용
- 소프트웨어 개발 모형 : 스크럼, XP, 크리스탈 ASD 등
- 개인과 상호작용, 문서보단 작동하는 소프트웨어, 계약보다는 고객과의 협력, 변화에 대응
evan-moon.github.io/2019/07/02/what-is-agile/
- MVC 아키텍처
- Model : 컨트롤러가 요청한 일을 처리
- View : 컨트롤러로 붙은 받은 결과값을 사용자 화면에 출력
- Controller : 일종의 조정자 역할, 모델과 뷰의 조정자 역할
- 좋은 코드란?
# 스파게티처럼 얽혀있지 않고 의존 관계가 없어야 한다.
# 주석은 무엇을 하는지가 아니라, 왜 필요한지를 설명해야 한다.
# 데이터나 함수의 이름은 의미가 있어야 한다.
# 좋은 코드는 직관적이고 명확해야 한다.
# 좋은 코드는 테스트가 잘되어야 한다.
# 좋은 코드는 재활용이 가능해야 한다.
참조사이트