[스터디 1일차] - git / TDD / 객체지향 프로그래밍

0. 출처

https://github.com/alstjgg/cs-study

GitHub - alstjgg/cs-study: CS 스터디입니다

1. [git과 github]                                                               

1. GIT

- 버전관리 도구, 대표적 관리 도구엔 git과 svn이 존재

- svn과의 가장 큰 차이는 svn은 중앙 집중 관리식, git은 분산 관리식이라는 것입니다( 저장소를 여러개를 두고 분산관리 한다는 차이점이 존재)

- SVN은 소스 변경 사항과 히스토리가 서버에 즉시 반영되기 때문에 변경 사항 및 히스토리 관리가 용이하다. 그러나 중앙 저장소 데이터 손실 시 복구가 어려우며, 서버와 클라이언트 간 버전 관리에 문제가 생긴다는 단점이 있다.

 

2. GIT의 장점

-빠른 수행 속도

- 데이터 무결성 보장(원격과 로컬 저장소 분리)

 

3. Git workflow : 기본적인 파일 관리 흐름

- tracked : git이 알고있는, 저장소에서 관리하는 파일. 스냅샷이 존재한다.

- untracked : 그 외 파일

 

- Git에서 파일은 위와 같은 lifecycle을 가진다.

- unmodified : 수정되지 않은 파일

- modified : 수정된 파일

- staged : commit으로 repository에 기록할 파일이자 stage에 올라간 파일

 

4. 순서에 따른 파일 상태

1) Staging : git add를 통해 파일의 현재 상태를 stage로 올림 ( Untracked -> Staged, Modifed -> Staged)

2) Commit : git commit을 통해 stage에 올라온 파일을 version으로 만들어 저장 (Staged -> Version)

3) Push : git push을 통해 로컬 저장소에 있는 코드 변경 이력을 원격 저장소에 저장한다

4) Pull : git push 명령어를 통해 원격 저장소에서 로컬 저장소로 업데이트 한다. Merge 작업이 발생한다. git Merged를 사용한다. 

 

* 그 외 상태)

* Reset : Staging Area와 Working Directory 상태를 원래대로 되돌린다. soft 옵션은 "HEAD"만 옮기고 staging area랑 directory는 유지한다. hard 옵션은 "HEAD"도 옮기고 staging area도 비워서 해당 스냅샷으로 working directory를 되돌린다.

* checkout : 브랜치를 옮김 

 

5. git과 github 한줄 정리

git : 버전관리 도구

github: git을 여러 사람이 함께 사용하기 위해 클라우드에서 사용하는 버전관리 서비스

 

 

2. [TDD란 무엇인가]                                                                                       

1. TDD란?

- 기능 구현이 아닌 테스트부터 시작하는 개발방법

- 기능이 올바르게 동작할지 검증하는 테스트 코드를 작성하는 것. 즉 테스트 코드를 먼저 작성하고, 테스트를 통과하기 위해 구현 코드를 작성하는 방식

 

2. TDD 장점은?

- 설계에 대한 빠른 피드백이 가능하다

- 오버 엔지니어링 방지(요구 사항에 맞춰 개발 코드를 구현하면, 불필요한 코드를 작성하지 않고 필요한 만큼만 개발이 가능)

- 지속적인 코드 정리( 테스트 코드가 있으니까 코드를 리팩토링 하는데 불안함이 없다. 또한 코드의 품질이 향상될 것이다.)

- 높은 테스트 커버리지 

 

3. 단위 테스트와 통합 테스트의 차이? 

- 메소드 하나를 기준으로 잡고 메소드 하나가 제대로 동작하는지 잡는걸 단위 테스트라고 생각.

- A메소드와 B메소드로 이루어져서 C메소드의 기능을 만들때. 여러가지 기준이 섞인 테스트를 할 때 통합 테스트라고 생각

- 전체적인 플로우가 잘 돌아가는지 확인하는게 통합 테스트고 세부적인 하나하나의 테스트를 단위 테스트라고 생각

 

4. 테스트 커버리지의 이상적인 수치에 대한 견해

- 100 찍으려고 테스트 코드 짜느라 정작 기능 구현에 시간 뱃기지 말고 적당한 70 80으로 하고 정확한 기능 구현을 하는것이 좋을 것이다.

 

3. [객체지향 프로그래밍이란 무엇인가]                                                                   

1. 객체 지향 프로그래밍에 대한 오해

1) 객체는 클래스와 같다.

- 클래스는 객체를 위한 도구지, 둘은 같지 않다.

 

2) 객체 지향은 현실 세계를 모방하는 것이다?

- 특정 객체가 수동적이게 다른 객체에 의존적이게 되므로 객체 사이의 결합도가 올라가므로 유지 보수하기 나쁜 코드가 된다. 따라서, 현실 세계를 '온유'하는 것이지 모방하는 것이 아니다.

 

2. 객체 지향 프로그래밍의 핵심 키워드

1) 객체 : 식별 가능한 객체 혹은 사물. 다른 객체와 협력하는 역할을 맡으며, 역할을 맡는 순간 임무를 수행할 책임이 생긴다.

 

2) 협력과 책임, 역할

협력 : 시스템 목표를 달성하거나 문제 상황을 해결하기 위해 여러 객체가 참여하여 행동하는 것

책임 : 협력 속에서 본인이 수행해야 할 임무의 내용을 알고 수행하는 것

역할 : 동일한 목적을 가진 책임의 묶으밍며, 역할을 맡으면 임무를 수행할 책임이 생긴다.

ex) 치킨을 손님에게 배달하기 라는 협력을 완수하기 위해, 치킨 가게 객체는 치킨을 튀기는 책임을 수행하고 배달원 객체는 손님에게 치킨을 전달하라는 책임을 수행합니다.

메세지 : 객체는 메세지를 통해 다른 객체에게 책임을 다하라고 요구하면서 협력한다. 이 때 중요한 점은!!!! 무엇을 할지만 요구하고 구체적으로 어떻게 요구해서는 안된다(캡슐화). 디테일하게 다 얘기하면 결국 명령을 받는 객체는 수동적이게 되어서 유지보수하기 어렵다.

 

3) 자율성

- 첨에 언급한 것처럼 객체는 자율적이고 능동적으로 행동할 수 있어야 한다. 

 

3. 책임 주도 개발

- 현실 세계를 반영하기 위한 설계를 할 떄, 자칫하면 "데이터 중심적인 설계"를 하기가 쉽다. 특정 임무를 수행하기 위해 필요한 데이터들을 나열하다 보면.. 서로 알고있는 로직이나 데이터가 많아지고.. 결국 계속 얘기한 결합도 가 올라간다!!

 => 데이터 중심적인 사고를 하면 geter, setter같은 함수를 짜게 된다

=> 책임 주도 개발을 해야한다. 시스템이 사용자에게 제공해야 하는 기능인 "시스템 책임"을 파악하고, 더 작은 책임으로 분할하고.. 분할된 책임을 수행하는 적절한 객체를 찾아 책임을 할당한다.

 

4. 결국 객체는 무엇이냐?

- 현실의 개념을 추상화한 것이며, 객체끼리 서로 협력하고 역할을 맡아 문제 상황을 해결해야 한다.

다만 현실과 달리 객체는 능동적/ 자율적이어야 하며, 결국 객체지향 프로그래밍은 능동적이고 자율적인 객체들을 이용하여 새로운 세계를 창조하는 행위라고 볼 수 있다.