사내 개발문화 개선하기 - 깃허브 이슈 사용하기

 

이미지 클릭 시 출처로 이동됩니다.

 

 

 

 

 

개선 동기

LogBack 관련 포스팅을 훑던 도중에, 블로그 주인분의 깃 레포를 자연스레 보게 되었다.

 

Shin._.Mallang

 

 

오픈소스 기여도 많이하시고 꾸준하신 것 같아서 긍정적인 에너지를 막 받고있는 찰나에, 레포 하나가 눈에 들어왔는데,

1인 개발 프로젝트 레포에서도, issue를 적극 활용하는 모습이었다.

 

사내 두 서비스의 노드 기반 백엔드를 담당하고 있는데, 1인 개발이라는 같은 상황에서

기존 사내 해당 서비스의 개발 형태를 개선할 생각을 하지 못했던 나 자신을 되돌아보며 개선을 했으면 좋겠다 싶어서 남기는 포스팅이다.

 

 

 

 

 

템플릿 작성

이슈 템플릿은 위의 블로그 주인분의 해당 깃허브 레포에서, 라벨은 깃허브 마크다운 이모지를 찾아 자주쓰는 라벨을 선정하였다.

 

크게 기능개발, 버그수정, 기타 세가지 이슈를 만들 수 있게 작성했고 라벨링으로, 타이틀로 어떤 이슈인지 구분할 수 있게 작성했다.

 

 

 

 

 

도입, 그 후

 

 

 

 

개인 노션에 항상 일 단위의 작업 히스토리를 기록하고는 하는데, 굳이 해당 서비스를 운영하는데 다른 툴을 사용해서 시간적인 낭비를 해야하나 항상 의문이었다.

 

또한 협업 과정에서 기획자의 요구가 종종 변경되는데, 이전 작업 요청 사항들을 이전에 그런적이 없었다고 처음부터 이렇게 해달라고 하지 않았냐는 억지 요구를 할 때도 간혹 있었다. 물론 더 좋은 서비스를 제공하기 위해 서로 이해하고 넘어갈 수 있는 부분이다.

 

하나 더 붙이자면, 사내 여러 서비스들에서, 내가 담당하는 서비스들의 백엔드 담당은 혼자이기 때문에, 결국 해당 레포들은 혼자 관리해나가야 하는데, 굳이 협업 할 때처럼 빡빡하게 레포를 관리해야할까? 라는 생각에 사용하지 않았었던 것 같다.

 

막상 사용해보니, 기획팀과의 협업에서도 이점이 있고, 혼자 레포를 관리해나가는 측면에서도 이점밖에 없는 것 같다.

기획팀에서 굳이 나에게 물어보지 않아도, 이슈 자체를 기획팀이 작성하게하여 내가 이슈를 해결해나가며 개발하는 방향을 생각해봤을 때, 의사소통 비용도 줄어들고 나아가 생산성이 향상되지 않을까? 라는 생각을 했고 적극 어필중이다.

혼자 레포를 관리해나가는 측면에서도, 히스토리를 따로 기록하지 않아도 되고, 레포 하나에서 모든 문서화가 되기 때문에 이 또한 생산성 향상에 기여하지 않을까 싶다.

 

 

항상 다른 팀, 다른 개발자들의 업무 방식을 스캔하여 좋은 점을 좀 빠르게 시도해보고 흡수할 수 있도록 눈을 항상 돌려봐야겠다.

 

 

 

 

 

 

참고

지향하는 개발 문화

우리는 개발 문화에 진심입니다 – 화해 블로그 | 기술 블로그

[Git] Issue 생성 및 Pull Request 와 연동

GitHub로 프로젝트 관리하기 Part1 - 이슈 발급 부터 코드리뷰까지 | Popit

GitHub - Mallang-log/backend

Git commit으로 issue 종료하기