공유(Share;)란?

1️⃣ 🖼️ Background

공유(Sharing)란 무엇일까?

위키백과에 따르면, 하나의 개체나 자원, 정보, 지식 등을 여러 사람이 함께 소유하거나 사용하는 행위 를 뜻한다.

그렇다면, 공유에 대해 고찰하게 된 이유는 무엇일까? 이에 대해 내 경험을 바탕으로 정리해보고자 한다.

2️⃣ 🗣️ Review (with. comment)

개발을 진행하기 전, 요구 사항과 함께 업무를 할당받게 된다.

업무를 지시하는 팀장님께 요구 사항을 함께 전달받으며 이해가 안 되는 부분이나 구체화되지 않은 부분은 이야기를 이어나가며 명확하게 blue print 를 그려나간다.

• 이때, 1차 공유가 이뤄진다.

그리고, 개발을 완료한 뒤 보통 GitHub 나 GitLab 과 같은 플랫폼을 이용하여 Git 에 코드를 push 한 뒤, 동료들에게 공개가 된다.

• 이때, 2차 공유가 이뤄진다.

For example

이번에 개발한 내용 중, Zone(; 특정 구역) 에 관련된 기능 구현이 있었다.

1. Monday(클라우드 기반 업무 협업 및 워크 매니지먼트 플랫폼) 를 통해 요구 사항이 정리된 업무를 할당받는다.

• 이때, 추가 질문이 있을 경우 Comment 로 질문을 드리거나, Discord와 같은 채팅 어플리케이션을 통해 구체화를 진행한다.

2. GitLab을 통해 Merge Request 를 올린 뒤, Code review 를 진행한다.

위 프로세스에 따라 MR Template 구성은 다음과 같다.

• 참고 링크
• 리뷰어가 중점적으로 확인해야 할 사항
• .. etc.

나는 팀원 간의 공유를 위해서 여러 항목 중 위 두 개를 구체적으로 적는 편이다.

또한, 타인에게 내가 아는 내용을 설명할 때 아래와 같은 가정을 두고 진행한다.

당연히 타인은 내가 설명하려는 content 에 대해 context 가 없다.

상대방이 나보다 개발 경험이 많거나, 개발 지식이 많아도 현재 내가 설명하려는 내용에 대해 가장 잘 아는 건 현재의 나라고 생각한다.

따라서, 내가 아는 content 를 타인에게 100% 에 가깝게 전달하기 위해서는

• 두괄식 (;결론부터 강조해서 blue print 를 그리는데 도움을 주기 위함)
• 자세한 description (;설명이 필요한 부분에 대해 추가적으로 내용을 기재하여, 이해를 돕기 위함)

위 2개의 근거를 바탕으로 MR 을 작성해왔다.

그런데, 다음과 같은 Comment 가 눈에 들어왔다.

Sharing in code. (feat. comment)

이번에 개발한 API 는 버전에 따라 각각의 DB 에 다른 값들이 저장되고, v2 DB 에서 Read 를 하는 API 였다.

이때, MR 에 description 을 남겨놨다고 생각했지만 해당 comment 를 보는 순간 아! 하는 생각이 들었다.

작성자가 MR 에 강조하고자 하는 내용을 기재했어도, 코드와 일치시키는 건 리뷰어에게 달렸다는 것.

그리고 프로그래밍을 처음 배울 때, 마주했던 벽 중 하나가 떠올랐다.

보통 전공책의 구성은 코드에 대한 설명과 예시 코드로 이루어진다.

그리고, 위 두 내용을 유기적으로 연결해야 이해했다고 볼 수 있다.

하지만, 나의 경우 종종 매칭하기까지 시간이 좀 걸렸었다.

맥락 상, 이 개념이 이 코드를 나타내는 것 같은데 정확히 맞나..?

때론 맞을 때도, 틀릴 때도 있었고 공백이 생긴 채 이해한 경우도 있었다.

그렇기에, 업무를 진행할 때 잘 공유하기 위해서는 곳곳에 이해를 돕기 위한 장치가 있어야 한다고 생각이 들었다.

• 공유가 잘 되어서 해당 도메인에 대해 팀원 모두가 높은 이해도를 가진다면, 이는 다방면에서 Resource 를 줄일 수 있는 기회라고 생각했다.

Comment

그리고 내가 선택한 방법은 Comment, 바로 코드 속 주석이었다.

주석에 대해서는 많은 개발자들 사이에서 호불호가 갈리는 영역이라는 것을 인지하고 있다.

하지만, context 가 없는 사람이 코드를 보고 이해할 수 있어야 하지 않을까? 를 가장 중요하게 생각한다면 주석은 충분히 좋은 역할을 할 수 있을 것이라고 생각한다.

• 물론, 유지 보수도 잘 되어야 한다.
  • 가령, 요구 사항이 바뀌어서 주석 내용도 바뀌어야 하는데 코드만 바뀌고 수정되지 않는다면 오히려 본질을 잃을 수도 있다고 생각한다.

그래서, 위와 같이 MR 에서 전달하고자 하는 핵심 내용을 주석으로 간단하게 명시했다.

3️⃣ 📋 Remind

이전에도 종종 아래와 같은 생각을 한 적이 있다.

이미 MR 에서 명시한 내용인데, Comment 로 적혔던 까닭은 무엇일까?

아마 아래와 같은 이유들이 있을 것이다.

• 리뷰어 입장에서 내용을 확실히 이해한 것이 맞는지 체크하기 위함
• 이해가 잘 되지 않아서 질문을 하기 위함
• 본문 속 A 내용이 해당 code 와 일치한 것이 맞는지 확인하기 위함
• .. etc.

그리고, 이 모든 행위들은 특정 토픽에 대해서 서로가 온전히 이해를 하기 위해서 노력하는 과정이다.

따라서, 이 노력에 도움을 줄 수 있다면 이번에 시도한 주석 외에도 다른 좋은 방법이 있지 않을까? 란 생각을 이어나가는 요즘이다.