객체지향 Object Oriented
실제 세계를 모델링하여 소프트웨어를 개발하는 방법
객체
보고 만질 수 있는 것 , 지성적으로 이해할 수 있는 것 , 생각이나 행동이 추구하는 바
개념상으로 존재하는 것 등 모든 것이 될 수 있음
특징
캡슐화
관련 데이터와 알고리즘(코드)이 하나의 묶음으로 정리된 것
자바 > 필드와 메서드를 캡슐로 감싸 보호해 외부로부터의 접근 제한
외부 세계와의 상호작용은 메소드 method 를 통하는 방법인데 라이브러리로 만들어 업그레이드 하면 쉽게 바꿀 수 있음
상속
상위 클래스의 모든 것을 하위 클래스가 물려받는 것 , 이미 작성된 클래스를 이어 받아 기존 코드 재활용해서 사용하는 것 의미 , 프로그램 쉽게 확장할 수 있도록 해주는 강력한 수단
다형성
같은 이름의 메서드가 클래스 혹은 객체에 따라 다르게 구현되는 것 , 하나의 이름(방법)으로 많은 상황에 대처하는 기법 , 개념적으로 동일한 작업을 하는 함수들에 똑같은 이름을 부여할 수 있으므로 코드 간단해짐
추상화
프로그램을 만드는데 필요한 부분만 파악/추출 필요 X -> 제거
장점
재사용성
상속을 이용해 코드 재사용
생산성 증가
객체지향 언어는 독립된 객체로 이루어져 있기 때문에 생산적으로 작업할 수 있고 유지보수 용이
자연스러운 모델링
객체는 세상에 존재하는 모든 것 , 객체지향 언어 자체가 우리가 살고 있는 세상과 닮아있다는 특징 존재 , 개발자가 생각하는대로 자연스럽게 구현 가능
단점
처리 속도
절차지향 프로그래밍보다 느림
개발 속도
난이도가 높아 객체의 역할과 기능을 이해해야만 프로그래밍 설계 가능
객체지향 언어
소프트웨어를 객체지향 방식으로 설계한 후 객체지향의 특성 ( 클래스, 객체, 상속, 추상화 등 ) 을 구현하는 데 사용되는 컴퓨터 프로그래밍 언어
순차적 처리 방식 , 프로그램 전체가 유기적으로 연결되어야 함
과거에는 하드웨어와 소프트웨어의 개발 속도 차이가 크지 않았음
but 소프트웨어 언어와 컴파일러의 발달로 하드웨어가 소프트웨어 따라오지 못하는 상황 발생
이러한 상황이 객체지향 언어의 등장을 이끌어 낸 것
장점
단점
유지 보수 어려움
구성 요소가 유기적으로 연결되어 있다는 것은 하나의 오류 발생할 시 , 전체 오류를 범할 수 있음을 의미 , 이는 문제를 해결할 때 일부분이 아닌 시스템 전체를 수리해야 함을 말함
비효율적
순서가 엄격해 코드 순서가 바뀌면 결과도 바뀔 우려 존재 , 언어의 융통성이 부족하여 생산 효율이 떨어짐
보안성 낮음 , 상속 불가능
절차지향 언어
비교적 큰 문제의 해결에 쉽게 사용하도록 고안된 고급 언어
Git
컴퓨터 프로그램 소스를 공유하고 협업하여 개발할 수 있는 버전 관리 시스템
장점
버전 관리
요구사항 반영 반복 > 코드 및 기능 수정
전체가 다시 저장되는 것이 아닌 업데이트된 부분만 저장
즉 , 불필요한 용량 차지를 줄이고 과거 버전의 코드로 되돌아갈 수 있음
협업
여러 명과 작업시 이메일이나 공유 드라이브로 소통하기엔 복잡 , 바로 업데이터가 되지 않고 코드를 가져오거나 에러가 발생할 경우 누가 어디를 잘못 건드렸는지 확인하기 불편함
각자 코드 수정 > 만든 것을 합침 > 업무 효율 향상
속도
각각의 개발자들이 모두 분산 처리 서버의 주인이 되는 셈 , 서버가 직접 해야 될 일 감소
분산 처리
서버와 클라이언트 뿐인 기존 형상 관리에 비해 분산 처리 구조를 유연하게 세울 수 있음 , 중간 서버를 두거나 부서별로 따로 서버를 두는 등의 구성 자유도 증가
단점
직관성
기존 형상 관리 도구에 비해 덜 직관적이고 배우기 어려움 , 로컬 머신을 작업 공간 , 서버를 저장 공간으로 생각하면 더 이상 복잡한 개념 필요 없이 체크아웃 후 파일을 수정하고 다시 커밋하기만 하면 되는 중앙집중형 도구에 비해 다층구조를 갖고 있어 다른 계층과의 상호 작용 방식이 복잡하게 연결되어 있어 혼동을 유발할 가능성 증가
다중 작업 불가능
한 번에 여러 브랜치나 여러 태그에 걸쳐서 커밋 불가능 , 본인이 만든 사소한 변동 사항이 다른 브랜치에 자동적으로 알려지지 않고 나중에 취합하는 시점이 되어서야 반영 > 충돌의 원인이 될 수 있음
Git repository
원격 저장소 remote repository
파일이 원격 저장소 전용 서버에서 관리
여러 사람과 함께 공유하기 위한 저장소 , 그 지역저장소와 연결되어서 동기화 되는 저장소
로컬 저장소 local repository
내 컴퓨터에 설치한 Git 과 연결할 저장소 , 실제로 Git 을 통해 버전 관리가 이뤄질 내 컴퓨터에 있는 폴더
일시적인 서버 장애가 있어도 개발 지속적으로 가능 , 서버의 자료를 가져와 로컬에서 병합하고 이를 다시 올리는 형태로 병합 문제 발생 감소
Git Keyword
$ git add [file name]
1번째 줄 : 커밋 내의 변경 내용 요약
2번째 줄 : 빈 칸
3번째 줄 : 변경한 이유
$ git commit -m "커밋할 내용"
한 줄의 커밋 메세지를 입력해 vim 에디터를 띄우지 않고 커밋 가능
$ git commit -am "모든 파일을 커밋"
-am 옵션을 주면 git add . + git commit -m 한 것과 같은 기능
$ git push
$ git fetch
로컬에는 없지만 리모트 저장소에 있는 데이터 모두 가져옴
$ git merge
$ git pull
$ git fetch
$ git merge
독립적으로 어떤 작업을 진행하기 위한 개념
여러 사람이 동일한 소스 코드를 기반으로 서로 다른 작업을 할 때에
서로 다른 버전의 코드가 만들어질 수밖에 없는데 이러한 상황에
여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능을 수행
git branch [branch name]
git branch
git switch [branch name]
branch rule
명명 규칙 : 보통 main 그대로 작성
배포할 수 있는 브랜치 , 최종적인 상태를 의미하는 공간 > 최상위 브랜치
명명 규칙 : 보통 develop 그대로 작성
다음 출시 버전 개발하는 브랜치
ain에서 분기되어 기능 개발을 위한 브랜치들의 병합을 위해 사용 ( 기능 병합, 버그 수정 후 배포 가능한 상태가 되면 main 으로 병합 )
명명 규칙 : feature / 기능 요약
기능을 개발하는 브랜치
새 기능이나 버그 수정이 필요할 때마다 develop 브랜치에서 분기 ( 여기서의 작업은 공유할 필요가 없어서 주로 자신의 로컬 저장소에서 관리 )
명명 규칙 : release/X.X.X or release-X.X.X
이번 출시 버전을 준비하는 브랜치
feature 브랜치에서 기능 개발 후 develop 브랜치에서 병합을 하는 과정 반복 , 최종적인 버그 수정이나 문서 추가 등 실질적으로 release 하기 직전에 하는 단계를 위한 브랜치
명명 규칙 : hotfix-X.X.X
출시 버전에서 발생한 버그를 수정하는 브랜치
갑작스럽게 수정해야 하는 경우에 main에서 수정하지 않고 hotfix 브랜치로 분기해 수정 후 main 으로 병합 ( main 에서 다시 배포 후에는 develop 브랜치에도 병합 )
Git에 프로젝트 관리 지원 기능을 확장하여 제공하는 웹 호스팅 서비스
Git 의 기본 기능을 포함하여 프로젝트 관리에 필요한 버그 추적 (bug tracking) , 기능 요청 (feature requests) , 작업 관리 (task management) , 위키 (wiki) 기능 등을 추가적으로 제공
GitHub 사용하는 이유
무료
Git 으로 관리하는 모든 코드들과 프로젝트를 GitHub에 무료로 전송해서 저장 가능
비공개로 올릴 때만 유료 , github 말고도 다른 서비스가 많이 있지만 가장 널리 이용함
분산형 버전 관리 시스템 DVCS
클라이언트가 저장소를 통째로 복제하여 사용하기 때문에 서버에 문제가 발생해도 클라이언트는 복제된 저장소를 다시 서버에 복사하여 서버 내 데이터 복원 가능
객체지향 / 절차지향 그리고 Git / GitHub 에 관한 기본적인 내용을 정리하며 스터디 진행