[도서 : 소프트웨어 개발의 모든 것] 정리

소프트웨어 개발의 모든 것

https://book.naver.com/bookdb/book_detail.nhn?bid=4924691 

소프트웨어 개발의 모든 것

 

중간 중간 결국 같은 이야기가 반복되어 지루한 부분도 있었지만...

당연하다고 생각하면서도 쉽게 지나치는 부분들을 콕 집어 정리가 되어있어서

개인적으로 필요하다고 생각되는 내용 위주로 정리해두고, 계속 공부해 나가고자 작성합니다.

 

개발이나 특정 툴에 대해서 다루는 자세한 사용방법은 아니지만! 공통적으로 어떤 부분을 체크해야 하는지,

일의 전체적인 순서는 어떻게 흘러가는지 참고하기에 좋은 것 같습니다.

 

(단, 개발에 대한 지식이 하나도 없고 개발자와 소통하기 위해 읽는 경우라면.. 책의 내용이 상당히 지루하게 느껴질 것 같기에... 필요없다 생각되는 부분은 과감하게 넘기면서 보는걸 추천드립니다.)

---

소스코드 관리시스템 사용시 지켜야할 규칙

- 소스트리 구조 및 이름 규칙

- 커밋(Commit) 혹은 체크인 규칙

- 로그 메시지에 대한 규칙

- 소스코드 리뷰에 관한 규칙

- 브랜치에 관한 규칙

- 태깅(Tagging) 에 관한 규칙

- 머징(Merging)에 관한 규칙

 

소스코드 관리시스템에 보관하지 말야아할 것

- 운영체제 및 개발 툴과 같은 개발 환경

- 빌드 결과물인 마스터 파일이나 바이너리 파일 (*.exe)

- 빌드 도중 생기는 중간 파일 ( *.o, *.obj)

- 제품 마케팅, 영업에 필요한 자료

 

브랜치를 해야하는 경우

- 제품 출시 후 유지보수와 동시에 업그레이드 프로젝트를 진행할 경우

- 이미 출시 된 제품에 복잡한 기능을 추가하는 경우

- 고객이 제품에 특정 기능을 넣어 달라고 요구하는데, 그 기능이 제품의 표준 기능에서 벗어날 경우

- 고객이 제품에 특정 기능을 넣어 달라고 요구하는데, 표준 기능으로 넣을 시간이 부족한 경우

→ 가능하면 적게 바뀔 기능을 브랜치로 사용하는 것이 좋다. 추후 트렁크(Trunk)와 머지를 고려해야 하기 때문

 

소스코드  관리시스템 사용 규칙

- 예외 없이 모든 프로젝트에서 사용해야 한다.

- 소스코드를 소스코드관리시스템 외에 다른 곳에 보관하거나 다른 툴을 이용하여 공유하면 안된다.

- 소스코드관리시스템을 개인파일 보관 장소로 이용하면 안된다.

- 소스코드를 백업용으로 체크인하지 않는다.

- 알파 버전 이후에는 버그 번호 없이 커밋하지 않는다.

- 소스코드관리시스템에 소스코드를 등록하거나 업데이트할 때남기는 로그 메시지는 반드시 표준을 따라야 한다.

- 브랜치는 꼭 승인절차를 지킨다.

- 브랜치를 만들 때는 머지계획도 같이 세운다.

- 브랜치나 태그의 이름을 정할 때는 표준을 지킨다.

- 매 마일스톤마다 태그를 만든다.

-  불필요한 파일은 소스코드관리시스템에 등록하지 않는다.

 

버전 관리 체계

버전 체계	표시방법	예	빌드번호 포함 예
2자리	major.minor	v 3.1 v 3.2	v 3.1 (build 1075) v 3.2 (build 1083)
3자리 (1)	major.minor.patch	v 3.1.1 v 3.1.2	v 3.1.1 (build 1075) v 3.1.2 (build 1078)
3자리 (2)	major.minor.stage	v 3.1.a1 v 3.1.b1 v 3.1.rc1	v 3.1.a1 (build 1075) v 3.1.b1 (build 1076) v 3.1.rc1 (build 1077)
4자리	major.minor.patch.stage	v 3.1.0.a1 v 3.1.0.b1 v 3.1.0.rc1	v 3.1.0.a1 (build 1075) v 3.1.0.b1 (build 1076) v 3.1.0.rc1 (build 1077)

- major : 큰 업그레이드

- minor : 작은 업그레이드

- patch : 몇 번째 패치인가

- stage : 개발 단계, 일반적으로 알파, 베타, RC 단계가 있다.

* 빌드 번호는 제품을 빌드 할 때마다 자동으로 1씩 증가하도록 설정

* 버전이 부여되면 제품을 통해서 제품의 버전을 확인할 수 있어야 한다. (프로그램 정보창을 통해 확인하거나 커맨드 라인 명령어 사용, README 파일등에 명시 등과 같은 방법)

 

백업 관리

- 1단계 : 실시간 미러링

- 2단계 : 일일 백업

- 3단계 : 주간 백업 및 안전한 장소에 보관

 

복구

- 연습하는 과정이 없다면 백업을 잘 해왔더라도 복구가 안되는 경우가 있다.

- 백업해둔 파일을 이용하여 주기적으로 복구하는 연습이 필요하다.

- 이 과정에서 백업시 필요한 데이터를 누락하지는 않았는지 확인할 수 있다.

 

개발 계획 단계에서 정해야할 것

- 프로젝트 이름

- 프로젝트 비전

- 프로젝트 목표

- 일정관리 계획

- 리소스 계획

- 이슈 및 리스크 관리 계획

- 프로젝트 성공 기준

- 유지보수 계획

- S/W 및 H/W 구매 계획

 

기타

- 작은 버그라고 하더라도 문제는 빠르고 정확하게 바로잡고 넘어가야 한다.

- 문서화 작업은 번거롭더라도 전체적인 일의 진행이 원활하게 이루어질 수 있는 중요한 지표다.

- 불필요한 곳에 시간 낭비하지 말자. (멀쩡한 소스코드 정리하기, 독특한 프로젝트 이름 정하기...)

- 1~2일 단위의 일정관리를 통해서 스스로 너무 늘어지거나 타이트 하지 않게 매일 작업 내용을 체크하는 것이 좋다.