형주라 같이 프로젝트 1달간 해보기

[rkdgusrnrlrl]

목적

• 형주에게 gitlab flow 로 일(?) 하는 법을 알려줌
• 장고에 대해서 공부함
• 같이 재미 있게 깃헙 하는 법을 고민함

상세 내용

• MyBook 프로젝트를 같이 진행 해 봄

[rkdgusrnrlrl]

3월 2일 배운 점 및 느낀점 정리

• Gitlab 의 머지 리퀘스트라 Github 의 풀리퀘스트라 별로 안다를 줄 알았는데, 리뷰 하는 과정이 있음. 잘 활용하면 코드 리뷰를 쉽게(?) 처리 할 수 있음
• 커뮤니티 툴로 slack을 쓰는데, 사실 Github 의 이슈로도 충분히 소통이 가능 Comment 를 활용해 토론을 하는 것이 Slack 을 쓰는 것보다 좋은 것 같음
• Github 에서 브랜치를 보호 하는 기능이 있는데 해당 기능을 걸면 로컬에서 해당 브랜치를 푸시 할 수 없음 오직 Pull request 를 통해 머지 할 수 있음. 이를 사용 하면 master 브랜치로 이상한코드(?) 들어가는 걸 중간에서 검증 할 수 있음
• Django 가 생각보다 기능이 많아 커스텀을 하려면 알아야 할 사항이 많은 듯 User 를 만드는데 Django 에서 기본으로 제공하는 것을 쓰려고 하니 인증 부분도 같이 봐야 할 것 같음. 추후 인증 시스템을 모듈화 하거나 만들때 좋은 참고가 될 것 같음
• 형주가 1주일 동안 1일1커밋을 했는데, 같이 프로젝트 해서 얻은 보람중 개인적으로 가장 큰 부분 임
• 확실히 혼자 하는 것에 비해 작업 속도는 떨어지나 같이 하다보니 계속적으로 관심이 생겨 꾸준이 할 수 있게 되는 것 같음

[rkdgusrnrlrl]

3월 8일 느낀점 정리

• 우선 장고 프레임 워크에 경의로움을 느낀다. 🌟
• 가장 놀라운건 이걸 수정 하면 저게 바뀔까 라고 해보면 진짜 바뀐다. 중요한건 생각 한데로 바뀐다. 물로 다는 아니다 :sob::sob:
• 많은 것들 장고를 지탱하고 있어 알아야 할 것이 많지만 문서화 가 잘 되어 있고, 코드도 파악 하기 쉽다.
• 재밌게 일하는 것에 대해 고민은 많이 하는데 요즘 emoji 를 많이 쓰기로 했다. 예전에 청진님은 그룹이나 채팅방에 emoji 를 많이 썼는데 그런 작은 것들이 캐주얼 함을 느끼게 해주는 요인이 아닐까 한다.
• 역시 가장 재밌게 일하는 가장 기본은 서로 많이 이야기 하고 소통하는 것이 필요 한 것 같다. 그리고 쓸때 없는 잡답도 일만 해야 하는 분위기를 좀 상쇄시켜 주는 것 같다. :relaxed:

[rkdgusrnrlrl]

3월 16일 느낀점

• 최근에 장고 form 쪽과 formView 쪽을 봤는데 정말 대단하다. 커스텀을 가장 적은 코드로 할 수 있는 게 놀랍다.
• 장고에 createView 가 있는데 등록시 사용하는 뷰인데, 이게 기능 한계가 있어서 formView 서 부터 필요 부분만 구현을 위해 내부 코드를 열어 봤는데 파악하기 쉬웠다.(코어 쪽은 지옥일지도...)
• 작업은 slack 보다 github을 더 많이 사용 하는게 효과적인것 같다. 토론 형태로 의견 교환 및 코드리뷰(?) 를 할 수 있어서 좋은 것 같다.

[rkdgusrnrlrl]

3월 17일 느낀점

• 상대방이 올리 풀리퀘 테스트가 상당히 고되다 풀리퀘 하나에 기능이 많이 들어가 있으면 테스트 전 부터 지친다 ㅠㅠ 풀리퀘 단위는 작게 테스트가 필요한 내용은 상세히
• 테스트 코드를 사용 면 좋지만 ui 테스트는 큰 편안함에는 큰 고통이 따른다. selenium 을 쓸까 고민 중이미만 배보다 배꼽이 더 클것 같아 패스...
• 최근에 LoginView 를 만들 었는데 역시 적은 코드로~
• 장고 하면서 블로그 들도 보는데, 사실 장고 공식 문서로 충분하다. 좀 더 자세히 알고 싶으면, LoginView ListView 등과 같은 녀석은 타고 들어가서 보면 View를 어떻게 구현 해야 할지 알기 쉽게 구성 되어 었다.
• 구현체 들이 하나의 예제와 같은 역활도 겸하고 있어 구현체 내부 메서드를 그대로 사용 하거나 커스텀 해서 사용 할 수 있다.
• 한사람이 치고 나고면 나머지 한사람이 힘들어 지는데 어떻게 하면 좋을지 고민 해봐야 겠다 ㅋㅋ

[ChangJoo-Park]

코드리뷰 문제는 저도 겪고 있는데요 매일 매일 PR을 처리하지 않으면 PR 크기가 너무 커지더라구요

서로 의식적으로 처리해야겠다라는 생각이 중요한거 같아요

어떻게 해야할까요

[rkdgusrnrlrl]

@ChangJoo-Park PR 하나의 크기가 큰다는 건가요 PR 자체가 많다는 건가요? 우선 저의 경우에는 PR 크기가 큰게 문제 인것 같습니다.

한 PR에 코드 수정 된 부분이 너무 많으면 직관적으로 파약 하기 어려운 것 같습니다. 그렇다보니 아 잘 돼겠지 뭐 하는 경우가 생기는 것 같아요. 의식적으로 하더래도 우선 PR 하는 사람의 부담감을 줄여 주는 게 중요한것 같습니다.

그러먼 아무래도 커밋 메세지에 신경을 써야 되고, 풀 리퀘스트도 좀 잘 정리 해두면 도움이 되는 것 같습니다. 그래서 5분 10분 내로 심심할떄(?) 할 수 있는 소일거리 정도 느낌을 줄 수 있으면 좋을 것 같아요(바람)

하지만 중요한거는 리뷰 자체도 하나의 중요한 일감(코딩과 같이)라고 마인드가 중요 하고, 뭔가 리뷰 자체를 즐길 수 있는 환경이 된다면 더 좋을 것 같습니다. 그런데 어떻게 하면 좀더 그런 분위기를 만들수 있을지 아직 저도 잘 모르겠습니다. ㅎㅎ

[ChangJoo-Park]

여기서는 pr하나의 크기였어요 한 pr이 계속 개발되어야하는 부분의 일부였을때 그 브랜치에서 계속 개발하다보면 최초 브랜치 의도와 다르게 되는 경우가 발생해서요

아직 프로젝트가 어느정도 수준까지 올라온 상태가 아니라 발생하는 문제일거라 생각하고 있긴해요

그래서 시니어개발자가 베이스를 다 깔아주어서 다른사람들이 독립적으로 개발할 수 있도록 해야하지 않을까 생각해봤어요 여기에는 테스트, 코드 보일러플레이트 등이 있을거같아요

[ChangJoo-Park]

깃헙을 쓰시면 #이슈번호 를 커밋메시지에 강제해보는것도 괜찮지 않을까요

http://ohyecloudy.com/pnotes/archives/git-add-branch-name-to-commit-message/

https://robots.thoughtbot.com/better-commit-messages-with-a-gitmessage-template

[rkdgusrnrlrl]

@ChangJoo-Park 코드 보일러 플레이트는 정말 큰 도움이 될 것 같습니다. 코드의 일관성만 보장되도 한결 보기 수월 꺼 같아요 ㅎㅎ 브랜치 자체가 이슈 기반으로 가고 있는데, 딱히 커밋 메세지에 이슈 번호를 강제 하진 않는데, 혹시 커밋 메세지에 이슈 번호를 넣으면 더 도움이 될까요??

[ChangJoo-Park]

나중에 머지되었을때 작업한 브랜치는 지우게 되는데 그러면 어떤 이슈에서 작업한 내용인지 찾기 어려울거같다는 생각이었어요

[rkdgusrnrlrl]

최종 정리

• 1달 넘게 지났고, 많은 느낌점이 있어 정리하고 이슈를 클로즈 함
• 우선 커밋을 쪼개고 메세지를 잘 적어주면 리뷰하기가 정말 좋은 것 같음
• 아직 github의 리뷰 시스템의 이해가 부족하긴 한 것 같음
  • padding 이 언제 완료가 되는 지 모르겠음
  • review 를 달아도 start review 인가를 하지 않으면 상대방에게 보이지 않는 것 같음
• project 를 잘 활용 하면 일을 병렬(?)로 처리 할 수 있어 좋을 것 같음(도입해보지 못했음)
• 확실히 테스트 코드가 있으면 테스트가 좀 더 용이 할 것 같음(하지만 시간이....)
• 같이 프로젝트는 1달 정도가 괜찮은 것 같음 1달이 지나면 초창기 템포(?)가 나오지 않음
  • 즉 계획은 1달 동안 할 수 있는 정도 정리 하는 것이 좋을 것 같음
  • 추가 기능은 다시 1달을 추가하는 형태가 낫지 않을까 생각
• 확실히 규칙을 정하고 하는 것이 필요한것 같음.
• 되도록 이슈를 통한 토론 및 의견 교환을 하는 것이 좋은 것 같음
• 풀리퀘나 이슈에 대해 하루에 한번 정도 액션을 해줘야 함
  • 리뷰를 못해 주면 언제 리뷰 해 주겠다 라고 적어 주면 좋은 것 같음 하지만 되도록 빨리 처리 해주는 것이 좋음