1. 프로젝트 관리의 중요성
프로젝트는 일정한 기간 안에 일정한 목적을 달성하기 위해 수행하는 업무의 묶음이다.
하나의 프로젝트는 정해진 기간, 배정된 금액, 투입인력 등 일정한 제약조건 하에서 각종 요구사항(requirement)을 수행하는 방식으로 진행된다.
-> 즉, 하나의 프로그램을 만들기 위한 일련의 프로세스다!
최근에는 개인과 팀 프로젝트의 위상이 비슷해졌지만 회사에서는 팀 프로젝트를 주로 하게 되기 때문에 협업 툴을 사용하고, 협업을 하는 프로젝트가 중요할 수 밖에 없다. 협업을 잘하는 개발자가 되는 것이 중요한데, 협업에서는 "공유" 하는 것이 중요하다. (코드 공유, 문서 공유, ..)
근데 코드만 공유하면, 내가 어떤 코드를 짠 것인지 다른 사람이 바로 이해할 수 있을까?
그래서 사용하는 것이 바로 리드미인데, 리드미는 단순하게 설명서 역할을 하는 파일이라고 보면 된다.
리드미는 크게 2가지 역할을 하는데, 1. 완성된 프로그램의 설명서 2. 구현중인 프로젝트의 현황이다.
2. 리드미
리드미는 프로젝트의 성공과 직결되기 때문에 잘 쓰는 것이 중요하다. 리드미는 마크다운 문법을 사용해서 작성한다.
리드미
- 확장자: .m(ark)d(own) -> .md
- (사실 Readme.txt 로 작성해도 괜찮음)
markdown 이 무엇?
-> 텍스트를 가독성 있고 예쁘게 보여줄 수 있는 기술
-> 텍스트를 웹 전용 텍스트로 변환해주는 기술
-> 읽고 쓰기 쉽게 하는 것이 목적인 기술
깃허브의 markdown 은 markdown 을 일부 변형한 Git-Flavored Markdown 을 사용한다. (좀 더 개발자 지향적이라고..)
참고로 디스코드도 깃허브와 같은 마크다운을 사용하고 있다고 한다.
마크다운 사용법
- 글머리
글머리 글씨 크기를 # 로 조절할 수 있으며, 1~6까지 지원하고 있다.
# ProgrammersTIL H1
## ProgrammersTIL H2
### ProgrammersTIL H3
#### ProgrammersTIL H4
##### ProgrammersTIL H5
###### ProgrammersTIL H6
- 순서가 있는/없는 목록
- 순서 있는 목록 -> 숫자 사용
- 순서 없는 목록 -> - / + / * 사용
- / + / * 아래 적용 결과를 보면 어떤 기호를 사용해도 동일한 결과로 나온다.
근데 같은 기호를 사용했을 때 같은 그룹으로 보고, 다른 기호를 사용하면 다른 그룹으로 보기 때문에 연속된 목록에서 - / + / * 을 섞어서 사용하면 아래와 같은 결과가 나온다. (1,2 / 3,4 / 5,6 과 다르게 7,8,9 는 좀 떨어져 있음)
순서가 있는 목록
1. 순서가 있는 목록1
2. 순서가 있는 목록2
3. 순서가 있는 목록3
순서가 없는 목록
- 순서가 없는 목록1
- 순서가 없는 목록2
+ 순서가 없는 목록3
+ 순서가 없는 목록4
* 순서가 없는 목록5
* 순서가 없는 목록6
- 순서가 없는 목록7
+ 순서가 없는 목록8
* 순서가 없는 목록9
그리고 순서가 없는 목록은 여러 기호를 섞어서 아래와 같이 사용할 수 있다.
사실 같은 기호를 사용해도 들여쓰기를 하면 같은 결과가 나오지만, 혼합해서 사용하면 느껴지기에 더 안정적이다.
여러 기호 섞어서 쓰기
- 기호1
- 기호1
- 기호1
- 기호2
+ 기호2
* 기호2
- 강조 (기울이기, 굵게, 기울이고 굵게...)
강조 (기울이기, 굵게, 기울이고 굵게...)
_기울이기_
**굵게**
**_굵게 기울이기_**
- 코드 입력
코드 작성
print('공백4칸')
공백이 사라지면 코드 종료로 인식
```
print('``` 사용)
```
추가로 코드를 작성할 때 ```언어이름을 쓰면 문법강조(Syntax highlighting)가 가능하다.
```python
for i in range(5):
print('python')
```
```javascript
for (let i=0; i<5; i++;) {
console.log('javascript')
}
```
- 인용문
인용문
> 인용문
> > 인용문
> > > 인용문
> > > > 인용문
깃허브에서 쓰는 마크다운 문법을 알아보기 위해 구글링하다가, 잘 정리된 깃허브를 발견해서 참고했다.
https://gist.github.com/ihoneymon/652be052a0727ad59601
마크다운(Markdown) 사용법
마크다운(Markdown) 사용법. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
3. 깃
깃은 버전 관리를 해주는 도구이고,
버전이란 유의미한 방향으로 수정일 일어나는 것을 말한다.
그렇다면 버전 관리의 필요성이 뭘까?
사실 이 짤 한 장이면 긴 말 필요없이 설명이 가능할 것 같다.
각 파일들은 각 파일들의 최종 버전이다. 프로젝트 결과 보고서_1126 은 그 버전 기준 완성본인 셈.
버전 관리를 하고 있다면 찐으로 최종 버전까지 만들었지만 맘에 들지 않아서 이전 버전으로 내고 싶을 때 저장되어 있던 이전 버전을 내면 된다.
하지만 많은 수정을 하게 된다면 수기로 버전을 기록하는 것이 불가능하므로, 버전 관리 시스템을 사용해서 버전 관리를 해 업무의 안정성을 보장해야 한다.
Version Control System
- 버전 관리
- 백업 복구
- 협업
버전 관리 시스템의 종류는 크게 3가지로 분류한다. -> 로컬 VCS / 중앙집중식 VCS / 분산 VCS
1. 로컬 VCS
- 로컬 = 내컴퓨터 안에서만, 즉 협업 불가
- 백업 O, 복구 O, 협업 X
간단하게 말하자면, 이렇게 혼자서 버전관리 하던 것을 버전 관리 시스템을 사용해서 조금 더 쉽게 하는 것이라고 생각하면 된다.
2. 중앙집중식 VCS
- 별도의 서버에 버전들을 모두 저장해놈
- 내 컴퓨터로 필요한 "파일만" 가져와 작업 (필요한 버전 프로젝트를 몽땅 가져오는 것이 아님)
- 서버랑 네트워크만 연결되어 있으면 필요 파일을 가져가서 작업하면 되므로 협업 가능
- 백업 O, 복구 O, 협업 O
- 대표적 - SVN, CVN
3. 분산 VCS
- 내 컴퓨터와 서버에 모두 버전을 저장
- 서버에서 프로젝트를 "통채로" 들고와서 작업하고, 작업이 끝난 프로젝트를 "통채로" 서버에 올림
- 통채가 뭐가 좋지? 범위가 뭉텅이가 되므로 관리 포인트가 줄어들어 훨씬 안정적이고 편함
- 대형 프로젝트에도 적합
- 백업 O, 복구 O, 협업 O
- 대표적 - Git, Mecurial, Bazaar
'TIL with Programmers' 카테고리의 다른 글
[TIL] 8/20 웹(Web), 인터넷, 클라이언트-서버, 프론트엔드, 백엔드 (0) | 2024.08.20 |
---|---|
[TIL] 8/19 협업 Tool(Trello, Jira, Notion) 사용하기, 애자일, 스프린트, 스크럼 (1) | 2024.08.20 |
[8/16] merge, fetch, pull, pull request, branch, fast-foward, 3-way (0) | 2024.08.16 |
[TIL] 8/14 로컬 저장소와 원격 저장소 연결하기/연결 끊기, git push, git clone, git pull, 브랜치 (0) | 2024.08.14 |
[TIL] 8/13 깃과 깃허브, 깃 명령어, CLI vs GUI (0) | 2024.08.13 |