소스 컨트롤과 셀프 컨트롤
우리가 싸워야 할 대상
- 우리 자신, 그리고 우리 자신의 바보 같은 실수
- 동료, 그리고 동료의 바보 같은 실수
- 협동 개발 과정에서 일어나는 문제점
- 기계적인 고장 (컴퓨터 파열이나 하드 디스크 증발)
- 소프트웨어를 악용하고 싶어 하는 도둑들
당신의 정신 건강과 당신의 행복과 당신의 생계가 모두 이 장의 내용에 달려 있다
우리의 책임
안전하고 보안이 잘 된, 접근이 용이한, 재생산이 가능한, 유지보수가 쉬운
소스 컨트롤
이 툴은 소스 코드의 중앙 창고 역할을 하면서, 그에 대한 접근 권한을 부여하고, 소스 코드에 대한 동시 수정을 정렬하는 일을 한다
소스 컨트롤은 소프트웨어 개발에 필수적인 툴. 팀의 안정한 협동 작업을 위해서 극히 중요.
엄격한 잠금
변경하지 않은 파일을 다시 놓아줄 때까지 다른 사람들은 그 파일을 편집할 수 없게 된다
낙관적인 잠금
소스 컨트롤 시스템에서는 여러 사용자들이 동시에 같은 파일을 편집할 수 있다
리비전 컨트롤(revision control)
파일을 체크인할 때마다 생기는 차이가 기록된다
전체 개발 히스토리에 속하는 모든 버전의 파일을 얻을 수 있다
버전 컨트롤 시스템이라고 한다
- 당신이 한 변경을(히스토리의 어느 시점에 한 변경이라도) 취소할 수 있다
- 소스 코드에 대한 작업을 하면서 변경을 추적할 수 있다
- 각 파일에 대한 변경을 누가 언제 했는지 볼 수 있다(그리고 특정 제품에 대해 한 명의 개발자가 얼마나 많은 일을 했는지 알아보는 복잡한 검색까지도 가능하다- 이런 기능은 특히 몇 년에 걸쳐서 진행되는 개발에 유용하다)
- 특정한 시점의 레포지터리 내용을 체크아웃할 수 있다
소스 컨트롤 시스템에는 어떤 종류의 파일을 넣어야 할까?
- 모든 소스 파일
- 빌드를 위한 뼈대
- 단위 테스트 코드와 모든 테스트 장비
- 배포본의 패키징에 필요한 그 밖의 모든 파일들 (그래픽 파일, 데이터 파일, 구성 파일 등)
궁극적인 목표! 레포지터리로부터 꺼낸 것을 가지고 전체 빌드를 수행할 수 있도록 만드는 것
=> 코어 엔진팀은 이렇게 하고 있음! :make를 타이핑하는 것으로 완전한 제품이 만들어 짐
접근 제어
소스 컨트롤 툴은 코드베이스의 어느 부분에 어느 사용자가 접근하는지도 통제
빌드마스터가 관리 (이재춘 팀장님)
레포지터리 가지고 작업하기
조금씩 자주 체크인하는 방법을 사용하자
레포지터리에는 라벨을 사용해서 중요한 이정표마다 표시를 할 수 있고, 그렇게 하면 가끔씩 많이 체크인하는 접근 방법의 이점을 얻을 수 있다
소스 트리에 브랜치 만들기
- 한 코드베이스에 동시에 여러 개의 기능을 추가할 수 있다
- 개인적인 작업 공간이 제공된다. 각 개발자는 그 작업 공간에 자기가 작업 중인 (문제가 있을 수도 있는) 코드를 체크인할 수 있다, 이렇게 하면 전체 코드베이스를 망가뜨릴 수 없게 된다
- 새로운 버전의 소프트웨어를 가지고 작업을 하면서, 예전 버전의 소프트웨어를 유지보수 할 수 있다
소스 컨트롤에 대한 간단한 역사
1972년 Bell 연구소에서 개발된 SCCS(Source Code Control System)는 모든 버전 컨트롤 시스템의 아버지이다
Subversion은 CVS의 결정 대부분을 개선하고 있다
구성 관리 (형상 관리)
시스템의 구성 변경을 체계적으로 관리하기 위해 여러 가지 시점에서의 구성을 식별하고, 시스템의 일생 동안의 구성의 무결성과 추적 가능성을 관리하는 분야
백업
반드시 확고한 백업 절차를 수립해야 한다
당신이 한 일을 백업하라. 재난이 일어나기를 기다리지 말고, 복구 정책에 대해 생각하라
소스 코드의 릴리즈
소스코드가 예기치 못했던 방법으로 릴리즈되는 것을 경계하라: 실행 파일이 쉽게 리버스 엔지니어링 (reverse engineering)될 수 없도록 예방하라
소스 코드를 어디에 두든
접근 가능하면 안 된다. 로그인 패스워드는 반드시 비밀로 유지
좋은 프로그래머는…
- 자기가 한일에 대해 책임을 지고, 코드 개발을 안전하게 보호하는 방법을 알고 있다
- 소스 컨트롤을 신중하게 사용하고, 항상 레포지터리를 일관성 있고 사용 가능한 상태로 만들어 둔다
- 망가진 코드를 절대 소스 컨트롤에 체크인 하지 않는다
- 유지보수하기 쉽고 사용하기 쉬운 코드를 만들겠다는 의도를 가지고 모든 툴을 신중하게 사용 한다
나쁜 프로그래머는…
- 재앙이 일어나기 전까지는 코드의 안정성과 접근 가능성에 대해 신경을 쓰지 않는다
- 코드의 백업과 안전에 대해서 다른 사람이 생각할 것이라고 추측한다
- 문서의 업데이트에 신경을 쓰지 않는다
- 레포지터리에 있는 자기 코드의 상태에 대해 신경을 쓰지 않는다 - 망가진 코드를 체크인하고, 자기가 어질러놓은 난장판을 다른 사람이 치우라고 그대로 둔다
'프로그래밍 > Code Craft' 카테고리의 다른 글
[5부 프로세스의 일부] Chapter20 사냥감 확인하기 (0) | 2017.11.30 |
---|---|
[5부 프로세스의 일부] Chapter19 규격화하기 (0) | 2017.11.28 |
[4부 프로그래머의 무리] Chapter17 여기 우리 함께 서 있네 (0) | 2017.11.24 |
[4부 프로그래머의 무리] Chapter16 코드 멍키 (0) | 2017.11.19 |
[3부 코드의 모습] Chapter15 소프트웨어의 진화 또는 혁명? (0) | 2017.11.18 |
댓글