code review group 운영방안

대상

• JavaScript, React.js, Vue.js, Node.js, Angular.js 등 사용자
• 프론트엔드개발관련종사자 (특히 주니어 개발자 또는 예비개발자)
• 코드리뷰문화를 체험해보고자 하는 예비 개발자
• 내가 짠 코드가 문제는 없지만 잘 짜여졌는지 제 3의 눈으로 확인하고픈자
• 정답은없다 여러가지방식의 코드작성을 통해 뇌를 말랑말랑 유지하려는자
• 지속적인 스터디와 동기부여가 필요한 사람
• 다양한 정보공유
• 뭐든 해야할것같은데 목적의식 목표의식이 없다!

환영합니다

• 현업종사자
• 블로그나 github을 활발하게 유지하시는분
• 나의 지식으로 주니어 개발자들의 성장을도우며 보람을 느낄사람
• 오픈소스생태계는 위대하다 생각하는 사람
• 다른사람의 의견도 겸허히 수용하며 반박이 아닌 의견제시를 할 수 있는 사람

목적

• 건전한 코드리뷰 문화 형성
• 주니어개발자들의 코드리딩 업그레이드
• 커밋코드 다시보자 내가짠 코드 내가 못믿는다 확인과정
• 활발한 커뮤니티로 다양한 사례를 접하고 데이터를 축적
• 영문이아닌 한글코드리뷰 및 프로젝트 업로드를 통해 오픈소스에 쉽게쉽게 기여하기

계획

• 초반 사람이 일정인원이상 모일때까지는 온라인으로 자유롭게 진행
• 사람이 모이게되면 지역별로 혹은 주제별로 한달에 한번정도 오프라인으로 만나 발표진행

규칙(필독)

• 싸우지마세요 건전한 코드리뷰문화를 만들어 나가는게 첫번째 목적입니다.
• 코드작성, 프로젝트에대한 설명, 자세한 주석 등 다른곳에서의 방식을 따라하지말고 꼭 자신의 생각으로 적어주세요
  ex) 함수형프로그래밍이 좋다고 함수형으로 짜는것이 아니라 함수형프로그래밍이 좋다는데 난 그게 뭔지 모르겠어서 그냥 이해한 방식대로 프로그래밍 하였습니다.
• 모르는 부분은 구글링을 하면서 찾아가면서 프로젝트를 제작합니다.
• 질문을 할떄는 상세하게 적어주세요
  • 어떤 문제를 겪고있는지
  • 본인이 시도한 방법들은 어떤게 있었는지
  • 왜 실패한것같은지
  • 무엇을 어떻게 하고 싶은지
• 코드리뷰에대한 의견은 자유롭게 적어주세요
  • 보기어렵다
  • 이해가 안가는 코드가있다
  • 함수명 클래스명 등 작명이 적절하지 않은것같다.
• 다 완성하지 못하겠으면 할 수 있는 부분까지라도 꼭 구현 부탁 드립니다.

시작하기전에 읽어보기

• 코드리뷰문화
• git flow
• Naver Open Source Guide
• git tip!
• git 초보의 pull request
• 기본적인 코딩 스타일 가이드

카카오톡 오픈채팅방

• 카카오톡 오픈채팅방

  장점
  실시간 채팅 및 정보공유

  단점
  대화가 많이 쌓이면 묻힌다.
  대화의 주제가 일관성이없다.

  그래서 가급적 오픈채팅방은 간단한 질문과 답변
  업무 또는 개발관련 자료공유 및 대화로만 이루어 졌으면 합니다.

slack

• Slack Link

  주제별 테마별 대화공간을 만들고 관련된 이슈에 대해서만 집중해서 커뮤니케이션을 할 수 있도록 하려고 합니다.

github

• github repogitory

  깃헙에서는 프로젝트별로 폴더를 생성해두고 샘플파일을 업로드 해 놓을건데 같은 방식으로 포크를하여 해당프로젝트에 개인폴더를 생성하고 프로젝트를 진행 업로드 해주시면 됩니다.

  최대한 상세한 주석과 왜 이렇게 작성했는지 어떤 어려움이 있었는지도 README.md 를 만들어 스펙과 세부사항을 적어 올려주시면 더 자세한 리뷰를 받으실 수 있습니다.

참여 및 기여 방법

clone git

1. Fork 를통해 자신의 깃헙으로 복사해갑니다.
2. git clone 레포지토리주소 명령어로 로컬에 다운받고 연결합니다.
3. $ git remote add real-blog(별명) https://github.com/kangyongseok/js-code-review-group.git 로 원본 프로젝트 저장소를 원격저장소로 추가합니다.
4. git remote -v 로 연결여부를 확인가능합니다.
5. git flow 를 사용할거기때문에 git flow init 을 하고 기본세팅을 진행합니다.
   • git flow 설치방법

   Branch name for production releases: [master] 
   Branch name for "next release" development: [develop] 
   
   How to name your supporting branch prefixes?
   Feature branches? [] feature/
   Bugfix branches? [] bugfix/
   Release branches? [] release/
   Hotfix branches? [] hotfix/
   Support branches? [] 
   Version tag prefix? [] 
   

git flow 사용한 브런치 생성

1. 해당작업을 완료하고나면 js-code-review-group git:(master) => js-code-review-group git:(develop) 으로 바뀌었을겁니다.
2. master 브랜치는 직접 건들이지 않고 develop 브런치에서 새로운 브런치를 생성해서 본인의 작업을 진행합니다.
3. 이때 브런치의 명이 중복되지않도록 자신의닉네임_project 로 폴더명 통일성을 지켜주세요 이유는 보기좋으니까 입니다.
4. 새로운 브런치생성은 git flow feature start 브랜치이름 으로 새 브런치를 생성합니다.

pull request

1. 작업을 마치면 git add => git commit => git push feature/branchName 으로 생성한 로컬브런치에 푸시를 완료하고
2. git checkout develop 으로 develop 브런치로 이동하여 git pull 을 통해 로컬브런치를 최신상태로 유지하고
3. 다시 feature 브런치로 돌아와 git rebase -i develop 을 통해 최신상태의 develop 브런치와의 재정렬을 하고 충돌난 부분을 수정합니다.
4. git push --force 로 수정된 작업들을 다시 최신상태로 업데이트하고
5. git flow feature finish branchName 을 하면 develop 으로 작업한 기능을 게시하게 됩니다. (js-code-review-group git:(develop) 브런치로 다시 되돌아오게됩니다.) 생성했던 브런치는 삭제됩니다.
6. git push 를 통해 로컬에서 리모트영역으로 푸쉬를 진행합니다.
7. 이후 pull 리퀘스트를 master가 아닌 develop 브런치로 요청해주시면 됩니다.

위와같은 방법으로 git 을 진행하는 이유는 최대한 실무와 연관성있도록 푸쉬하기 위함입니다.
개개인이 각자 폴더를 생성하여 푸쉬하기때문에 충돌가능성은 거의 전무하지만 실무에서는 협업하다보면 충돌이 반드시 발생하게됩니다.
git 의 자세한 명령어와 git flow 에 관한 디테일한 내용은 직접 습득해보시기 바랍니다. 도움되는 링크는 시작하기전에 읽어보기 부분을 참고해 주시기 바랍니다.

기타 문의사항 및 개선사항 여기서 함께 해 보았으면 하는 프로젝트가 있다면 메일 로 연락 주시기 바랍니다.
풀리퀘스트 요청해주신 프로젝트폴더들은 매주 일요일 저녁 10시에 일괄 머지하도록 하겠습니다.