From 0c5beba954e1a12862942d53eed93cb503cebf20 Mon Sep 17 00:00:00 2001 From: Gael-Android Date: Fri, 15 Nov 2024 14:30:52 +0900 Subject: [PATCH] first try --- README.md | 2 + development-culture.md | 44 +++++++++++++++++++++ development-process.md | 87 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 133 insertions(+) create mode 100644 development-culture.md create mode 100644 development-process.md diff --git a/README.md b/README.md index d6027a4..04f17b5 100644 --- a/README.md +++ b/README.md @@ -4,6 +4,8 @@ ### 개발 문화 / 프로세스 +#### [개발 문화](./development-culture) +#### [프로세스](./development-process) ### 브랜치 전략 diff --git a/development-culture.md b/development-culture.md new file mode 100644 index 0000000..7389490 --- /dev/null +++ b/development-culture.md @@ -0,0 +1,44 @@ +# 개발 문화 + +## 1. 수평적인 조직 문화 +- 명령과 복종의 구조가 아닌, **상호 존중에 기반한 수평적 관계**를 지향합니다. +- 질문에 대해 사과할 필요가 없으며, 질문을 부담스럽게 여기지 않습니다. + - 특히 **기초적이거나 단순해 보이는 질문**일수록 더욱 자유롭게 할 수 있습니다. + - 질문을 받는 상황에서는 언제나 **적극적이고 친절하게 답변**합니다. + - 질문으로 인한 시간 소모를 염려하지 않으며, **질문도 중요한 피드백의 일종**으로 인식합니다. + - 깊이 있는 질문 또한 언제든 환영하며, 질문을 받는 것이 개인에 대한 **비난이나 공격이 아님**을 인지합니다. + +## 2. 피드백의 개방성 +- **모든 상황에서 피드백을 수용**할 수 있는 환경을 조성합니다. +- 피드백은 이성적으로 받아들이며, **긍정적이든 부정적이든 항상 선의로** 받아들입니다. +- 항상 **친절하고 예의 있는 방식**으로 피드백을 주고받습니다. + +## 3. PR(코드 리뷰) 자주 수행 +- **작은 단위로 자주 PR**을 수행하여 피드백과 검토의 부담을 최소화합니다. +- 주기적인 피드백을 통해 **코드 품질을 개선**하며, 진행 상황을 공유하고 조율할 수 있는 기반을 마련합니다. + +## 4. 공동 코드 작성 의식 +- 개인의 소유를 넘어서 **모두가 함께 사용할 수 있는 공용 코드**를 작성한다는 의식을 갖습니다. + +## 5. 스터디 참여 활성화 +- 다양한 스터디에 참여하여 **전문 지식과 경험을 확장**하고, 상호 간의 학습을 지원합니다. + +## 6. 유용한 자료 및 학습 자료 공유 +- 본인이 정리하거나 적용한 사례를 포함해 **유용한 자료를 공유**하며, 공동 학습에 기여합니다. + +## 7. 개인 활동의 공개 +- 학습, 개발 등 본인이 수행하는 활동을 **적극적으로 공개**합니다. +- **주제와 무관한 내용**도 공유할 수 있으며, 특정 플랫폼이나 기술에 국한되지 않습니다. + +## 8. 코드 개선 기회 활용 +- **기회가 생길 때마다 코드 품질 개선**에 적극적으로 참여합니다. +- 코드에 대한 소유권 개념을 벗어나, **누구나 기여할 수 있는 공용 코드**로서의 가치를 강조합니다. +- **회의시간, 슬랙채널, github issues** 등 간접적으로도 제안하거나 도울 수 있는 방법이 있습니다. + +## 9. 모여서 각자 코딩(모각코) 세션 +- 혼자서 문제를 해결하려 하기보다는, **다른 구성원들과 적극적으로 논의**하고 아이디어를 공유합니다. + +## 10. 주간 회의 +- **자유로운 근황 공유 시간**을 마련하며, 누구나 회의 안건을 추가할 수 있습니다. +- 관습적으로 진행할 필요없습니다. +- 회의내용을 회의록으로 남겨야합니다. diff --git a/development-process.md b/development-process.md new file mode 100644 index 0000000..d482d58 --- /dev/null +++ b/development-process.md @@ -0,0 +1,87 @@ +# 개발 프로세스 + +## 1. 코드 리뷰 (Code Review) + +### 1.1. 코드 리뷰의 목적과 과정 +- **코드 리뷰**는 PR(Pull Request)에 대해 피드백을 제공하고 코드의 품질을 개선하는 과정입니다. +- 프로젝트는 **공동의 책임** 아래 진행되므로, 코드 리뷰 역시 개발의 중요한 일부입니다. +- **최소 1명 이상의 팀원**이 리뷰를 진행해야 하며, 관련된 팀원들이 최대한 참여하는 것이 권장됩니다. _(Assignee가 아니더라도 의견을 남길 수 있음)_ +- 리뷰를 통해 다음과 같은 작업이 이루어집니다: + - 피드백 수용 및 코드 수정. + - 코드 스타일 변경, 질문, 개선된 코드 제시 등 다양한 방식 활용. + +### 1.2. 코드 리뷰의 기본 원칙 +- 피드백은 권위나 실력과 무관합니다. **잘하는 사람이 못하는 사람에게 하는 것이 아님**을 인지해야 합니다. +- 코드 리뷰는 **상호 학습**의 과정입니다. + - 남이 작성한 코드를 읽는 것만으로도 실력 향상에 도움을 줍니다. + - 같은 기능도 여러 가지 방식으로 구현될 수 있으므로, 리뷰를 통해 **시야를 넓히고 질문**합니다. +- 리뷰의 **친절함과 배려**는 필수적입니다. + +### 1.3. 작성자와 리뷰어의 역할 +#### 코드 작성자 +- 코드의 **오류 및 오타**를 확인합니다. +- **권장되지 않는 스타일**을 수정합니다. +- **주석**을 추가하여 리뷰어의 이해를 돕습니다. + +#### 리뷰어 +- 작성자의 **의도를 이해**하고 피드백을 제공합니다. +- **친절하고 배려 있는 태도**로 리뷰를 진행합니다. + +### 1.4. 리뷰 체크리스트 +- **코드 설계**: 코드가 잘 설계되어 있는가? 더 나은 방법이 있는가? +- **함수의 기능**: 함수의 역할이 명확한가? +- **복잡성**: 복잡한 구조를 단순화할 수 있는가? +- **변수 이름**: 변수 이름이 직관적인가? +- **코드 스타일**: 일관성을 유지하고 있는가? + +--- + +## 2. 이슈 생성 (Issue Creation) + +### 2.1. 이슈의 정의와 활용 +- **이슈**는 프로젝트의 문제, 제안, 개선 사항 등을 기록하고 관리하는 도구입니다. +- 과거에는 노션 칸반보드에서 이슈를 관리했으나, 현재는 **GitHub Issues**를 활용합니다. + +### 2.2. 이슈 생성 가이드 +- **자신의 코드뿐만 아니라 다른 팀원의 코드**에도 이슈를 등록할 수 있습니다. +- 관련 예시는 [Soomsil-Android Issues](https://github.com/yourssu/Soomsil-Android/issues)를 참고하십시오. +- **Assignees**: 이슈와 관련된 팀원을 추가합니다. +- **Labels**: 이슈의 성격(버그, 기능 추가 등)을 명시합니다. +- **Projects/Milestone**: 해당 기능을 활용하면 이슈 관리가 더욱 체계화됩니다. + +### 2.3. 이슈 제목과 내용 +- 제목은 **프로젝트 명**과 **핵심 내용**을 포함합니다. 예시: + - `[Soomsil 검색] 디자인 변경 사항 반영` + - `[Feature/Search] 검색 기능 추가` +- 내부 문서는 **마크다운 형식**을 활용하며, 실제 사례를 참조하여 작성합니다. + +--- + +## 3. PR (Pull Request) + +### 3.1. PR의 정의와 목적 +- **PR**은 브랜치 전략에 따라 분리된 변경 사항을 주 브랜치에 병합하기 전에 **리뷰와 동의**를 구하는 과정입니다. +- **자주**, **작게**, **명확하게** PR을 작성해야 합니다. + - **자주**: 변경 사항이 발생할 때마다 즉시 PR 생성. + - **작게**: 여러 기능이나 변경 사항을 하나의 PR에 포함하지 않음. + - **명확하게**: 상세한 설명과 시연 자료를 제공. + +### 3.2. PR 작성 가이드 +- [Soomsil-Android Pull Requests](https://github.com/yourssu/Soomsil-Android/pulls)와 같은 실제 사례를 참고합니다. +- 제목은 **프로젝트명**과 **핵심 변경 사항**을 포함합니다. 예시: + - `[Feature/Search] 검색 뷰 진입 시 키보드 활성화 기능 추가` +- PR 내용은 보통 다음과 같은 섹션으로 구성됩니다: + 1. **Summary**: 변경 사항의 요약. + 2. **Describe your changes**: 변경 전(As-is)과 변경 후(To-be) 상태를 설명. + 3. **To reviewers**: 관련된 팀원을 호출하여 피드백 요청. _(예: @yourssu/android-maintainer)_ + +### 3.3. PR의 중요성 +- PR은 팀 간 **소통과 협업**의 핵심 도구로, **개발 문화의 중심**입니다. +- 자주 PR을 올리고, 이를 통해 **피드백을 자주 주고받아** 코드 품질을 지속적으로 개선합니다. + +--- + +## 추가적으로 고려할 사항 +1. **자동화 도구 활용**: GitHub Actions, CI/CD 등을 도입하여 코드 검증을 자동화. +2. **문서화**: 코드와 PR 과정에서 문서화를 철저히 하여 프로젝트 가시성을 높임. +3. **주간 리뷰**: 정기적으로 이슈와 PR을 검토하고 진행 상황을 공유하는 회의를 통해 투명성을 강화.