[22.09.28] 오픈소스 SW PART.개발 협업, 형상 관리

서론

교과목 3주차 협업에 관한 내용을 정리해 보겠습니다.

 

 

본론

- 협업이란?

정의 : 공통된 규칙을 지키는 것

> 검증받지 않은 코드는 에러를 유발한다고 하여 100라인 이상 짜지 못하게 하는 회사가 있다고 합니다. (100라인 이상 짜면 버그가 발생할 확률이 높아집니다. > 코드가 긴 만큼 규칙을 지키기 어렵습니다.)

 

+ 혼자 만드는 코드는 그래도 돌아는 갑니다. 근데 같이 짤 때는 절대로 버그가 없을 수 없습니다. 하지만 우리는 프로젝트를 완성하기 위해서 혼자 할 수 없는 경우가 있으므로 협업을 해야 하고 따라서 규칙을 지켜야 합니다.

 

∴ 협업을 하는 위해 규칙을 만들어야 합니다! > 협업을 잘하게 해주는 협업 툴이 있고 협업 관리 툴을 잘 사용해야 합니다.

 

=> 형상관리(version control)

-> 형상 관리의 정의

소프트웨어의 변경 사항을 체계적으로 추적하고 통제하는 것

 

> 어떠한 문서나 파일이 변경된 경우, 변경된 내용과 그 원인을 기록하였다가 나중에 필요한 경우 찾아볼 수 있도록 하여 관리하는 것

 

-> 필요성

문서가 어떤 게 최신인지 누가 만들었는지 기록을 하기 위함입니다.

> 만약 팀플을 했는데 다양하게 생긴 산출물들이 누가 무엇을 쓴 지 모른다면 제대로 된 팀플을 한 게 아닙니다. 제대로 관리가 필요합니다.

 

+ 내 노트북에서는 잘 동작하는데 막상 배포하면 안 돌아가는 일이 형상관리를 안 해서 발생하는 것입니다.

 

-> 요소

소스코드만이 형상 관리가 아니고 분석, 설계, 구현, 테스트 등의 산출물도 형상관리를 해야 합니다. > ex) 요구사항 명세서, 프로젝트 계획서 등 요구사항이 바뀔 수도 있기 때문입니다.

 

+ 테스트에서는 버그가 있다면 무슨 버그가 있었고 누가 고쳤고 어떻게 고쳤는지 기록을 해야 합니다.

 

+ 과제에 대입해 보면

과제 기간 일주일 동안 1일차를 어떻게 뭘 했고 내일 뭐 해야 한다고 기록을 하는 것 > 한 가지 과제를 하기 위해 몇 가지 단계를 해야 한다고 기록을 하는 것입니다.

 

-> ex) ML 과제 면 lr을 바꾸기 위해 어떠어떠한 것을 해야 한다고 기록을 합니다. (이때 요구 날짜, 개발 시작 날짜, 완료 날짜를 적어야 합니다. jira 등 형상관리 도구에 적어야 하는 요소들이 다 있습니다.) + 이전에 했던 포켓몬 프로젝트에서 일자별 정리가 다 형상관리!

 

+ 프로젝트에 대입해 보면

간단하게라도 요구사항 명세서, 프로토타입, 프로젝트 계획서, 프로덕트 백로그를 작성해야 합니다. 그리고 이 문서들의 변경을 추적해야 합니다.

 

-> 예를 들어

1. 22년 9월 22일 김 과장님에게 zip 파일을 받았고 내가 그 파일을 수정해서 보내야 한다. (이게 메인타이틀)
2. 언제부터 언제까지 뭐를 했고, 언제부터 언제까지 검토를 하고, 언제부터 언제까지 피드백을 받고, 언제부터 언제까지 제출을 보내겠다. (서브 스토리)

3. 이것을 수행했다. 안 했다도 기록 (수행 여부)

=> 형상의 정의

아이템(제품)의 형상 + 아이템을 만들기 위한 디테일한 모든 것(문서, 설계도, ML 모델링, DB 등등)

 

-> 형상 관리 활동

1. 형상 식별
1) 형상 항목 선정 : "뭘 형상 관리할 건가" 정합니다.
2) 베이스라인 기준 선정 : 이 정도는 돼야 keep 할 수 있다는 기준이 됩니다.

2. 형상 제어 : 형상의 변경을 허가할 것인가 제어합니다.
3. 형상 감사
4. 형상 보고

 

> ★ 이러한 활동을 해봤나 안 해봤나의 경험 여부가 스펙 그 자체입니다.

결론

필요한 것 : 고객 문서, 개발 단계별 필수 산출물, 구매한 도구 관련 산출물, 품질 보증 활동 산출물, 모든 프로젝트 관리 활동 산출물 등등 > 형상관리를 제대로 하려면 캡스톤 같은 규모 있는 프로젝트를 마음이 맞는 팀원들과 함께해야 가능할 것 같습니다.