Prologue
전역한 친구들이나 현역들이 공통적으로 동의하는 군대에서 가장 기억에 남는 순간들 Best 2는
1.
훈련소 첫날 밤 혹은 둘째 날 아침
2.
전입날
일 거다. (뇌피셜)
많은 시험과 (공군이라면 모를리 없는) 정치를 거쳐 입대 전 부터 쭉 바라왔던 개발하는 보직에 들어오게 되고, 제일 처음 부대에 사무실에 왔을 때 받았던 충격을 아직도 생생히 기억한다.
아직 현역이라 보안 규정 상 자세히 서술할 수는 없지만, 첫 3개월동안 받은 느낌은 이러했다.
"위"에서 개발 요청이 내려오는 수직적 구조 + 군대식 문화 = ??????
Bash
복사
끔-찍한 혼종이었다... 그래도 개발 환경은 내가 속한 팀이 가장 좋다고 생각해서 그나마 위안이 되었지만, 전입한지 얼마 지나지 않아 선임이 개발 또는 메인테인하고 있던 프로젝트를 인수인계 받아 열어 보았을 때 다시금 멘붕이 왔다.
프로젝트를 전해주는 선임마저 이게 최신 버전인지 잘 모르고, 코드 컨벤션은 그러려니 쳐도 가장 압권이었던 것은 코드 곳곳에 자리한 주석들이었다.
// 후임아 미안하다... 내 능력이 이것 밖에 안되...(심지어 맞춤법도 틀림)
...
// 이 파트는 다른 변수랑 이렇게 저렇게 하면 되지 않을까? 모르겠다...
Java
복사
...(아임 그루트)
그 이후에도 몇몇 프로젝트를 맡았지만 같은 문제를 갖고 있지 않는 프로젝트는 아직까지 보지 못했다.
보통 프로젝트들은 SVN 식 VCS를 사용하고 있고, 올라가 있는 것도 놀랍게도 커밋이 1개... 그냥 위에서 어딘가에 올려두라고 하니깐 제일 최근 버전 올려둔 거 같았다. (올려가져 있는 버젼이 운영 중인 버전일 지는 미지수)
가장 큰 어려움은 상용에서 사용하는 프로그램, 툴, 심지어 라이브러리들까지 들여오기 전 결재를 받고 심의를 받을 후에 가져올 수 있다는 점이었다. 이 점은 군대 특성상 어쩔 수 없다고 받아들였다. 이 파트 외에도 보안 때문에 쓸 수가 없는 놀라운(!) 점들이 많다.
어떻게 하면 이런 것들을 줄일 수 있을까 고민하다가, 다른 선임과 같이 맡게 된 프로젝트에서 Git을 도입하면서 점점 물꼬가 트였다.
Problem Recognition
•
Readme + 주석 작성(필수)
◦
후임은 당신이 gunbun이라고 변수를 선언하면 뭔지 모른다...
◦
테이블 컬럼은 숫자로 작성하지 말자...
◦
뭐가 어떻게 돌아가는 지, 이 파트가 어떤 역할을 하는 지 제.발. 써두자
•
버전 관리하기
◦
반디집으로 버전 관리를 하면 후임에게 싸다구를 맞는 게 요즘 학계의 정설
◦
각 수정마다 내가 뭘 고쳤고, 뭐가 안되고, 고치려하는 게 뭔지 써 놔야 프로젝트를 받을 사람이 편하다 (ㄹㅇ)
◦
같은 프로젝트를 여러사람이 작업할 때, 바로 옆에 있다고 말로만 정하지 말고 코드로 써두자.
•
이슈 관리하기
◦
이슈 트래커 없는 거 아는데, 그래도 적어둘순 있잖아...
◦
어떤 이슈가 언제 해결되었는 지 알아야 시간 낭비를 줄인다. 야근 하기 싫잖아?
In Practice
부대에서 다른 병사들을 대상으로 자기 특기나 재능을 살려 세미나를 종종 여는데, 위 문제들과 다음과 같은 주제로 세미나를 진행했다.
Git과 협업 문화를 ARABOZA
•
협업 Philosophy
•
Readme 문서 작성하기
•
작업별로 커밋 정리하는 습관 들이기
•
Git 주요 개념 설명
◦
staging, commit, push, pull, branch, stash, tag, etc
•
브랜치 전략
•
인트라넷에서 협업하기
◦
git bundle, git patch, git apply, git am
•
Git-flow 아주 조심스레 어렴풋이 따라하기
•
밖에서는 어떻게 할까?
◦
오픈소스 컨트리뷰팅하기
◦
커밋으로 이슈 트래커 관리
◦
커밋/풀리퀘/이슈 Notification 받기
◦
CI/CD