코드 리뷰 문화 도입, 개선하기

	A	B	C	D	E	F	G	H	I	J	K	L	M
1		[발표자] 김재녕 / 송용주	최홍준	김충환	김형준	홍지운	박주진	표선동	서영수	김찬수	메이커준	반태형	송용주
2
3	코드 리뷰란?	* 개발자가 작성한 코드를 다른 개발자가 정해진 방법을 통해 검토하는 행위		코드를 작성한 사람이나 리뷰해주는사람 둘다 윈윈하는것!	서로 간의 컨텍스트를 맞추는 것			코드를 통해 서로에 대해 알아가고, 함께 성장하는 시간이라고 생각합니다			개인의 코드를 팀의 코드로 자라나게 하는 과정 (물주고, 햇빛 주고 등)	코드 오너십을 공유하고 일을 어떻게 했는지에 대해 지식을 공유하는것
4											ㄴ 비유가 멋지십니다 !
5	코드 리뷰는 왜 필요한가? 또는 왜 해야 하는가?	* 버그의 조기 발견 (Shift Left) * 집단 지성을 통해 다양한 해결책을 교류하여 프로덕션 품질 향상 * 성능 이슈, 아키텍처 설계 및 구조, 코드 품질 향상 기여 * 지식 공유를 통한 팀원들의 지식과 실력 상향 평준화 * 빠른 장애 대응 * 해당 작업에 대한 문맥을 기록으로 남길 수 있음		다른 사람의 관점에서 보면 자신이 볼 수 없었던 것들을 볼 수 있기 때문	요구사항 정리나, 모델링을 함으로써 구현의 초점을 맞출 수 있지만, 구현을 하고나서의 초점이 틀어질 수 있기 때문에 이를 맞추기 위해서는 꼭 필요하다고 생각합니다.	로직상 놓친 부분을 제 3자의 눈으로 확인해볼 수 있습니다.	코드의 퀄리티를 유지할 수 있고 상호 피드백을 통해 서로 성장할 수 있다고 생각합니다.	견문을 넓힐 수 있기 때문입니다	협업하는 팀에서 개발을 일관성있게 하여 생산성을 높이고 버그가 발생할 확률을 줄일 수 있는 것 같습니다.	코드 품질을 높이기 위해서	코드리뷰가 없다면, 나와 다른 사람의 코드가 연결되는 지점에서 잘 동작하지 않을 확률이 높기 떄문에, 코드 리뷰가 없다면 정말 운좋은 경우가 아니라면 코드가 하나의 생명체인 소프트웨어로 자라나기 어렵기 떄문에 (변화하는 모든 것은 결함이 있기 때문에) 불확실성을 낮추기 위해	사전에 잘못된 부분을 찾고 버그나 요구사항 변경이 있을때 다른 사람이 충분히 대응할수있도록 해야한다
6
7	반대로 필요 없다고 생각한다면 왜 필요하지 않은가?	* 개발 생산성 저하 (너무 느려~) * 장점에 대한 무지 (왜 필요해?) * 여지 껏 없이도 큰 문제 없이 업무 수행 (그런 거 없이도 잘만 개발했어!) * 코드 리뷰 실패 경험 (해보니 잘 안되더라고ㅠ)									불확실성이 낮고, 작은 규모의 토이 수준의 제품이라면 굳이 필요 없을것 같지만, 사실 우리가 만드는거는 이런게 거의 없으므로 해당되는 경우가 별로 없을것 같아요!	코드리뷰로 얻는 가치가 중요한 것이지 그 방법은 코드리뷰가 아니어도 된다고 생각합니다
8
9	코드 리뷰 문화로 얻는 이점	* 유지보수비용 절약, 장기적측면에서의 생산성 향상 * 팀원들의 동기부여 향상										컨텍스트공유, 명확한 피드백
10
11	코드 리뷰를 하다가 안하면 어떤 점이 불편할까?	- 자신의 소스에 대한 불신 및 걱정 - 버그 조기 발견 빈도가 적어져 추후 장애 대응 빈도가 높아질 것이라 예상 - 개인적으로 성장의 느낌을 받지 못할 수 있음		성장 속도가 줄어든다	- 조기에 못잡은 크리티컬한 버그가 운영 서버에서 발생할 수도..? - 내 코드가 과연 좋은 코드인지? 알 수 없을 것 같다. - 이슈에 대한 증거를 잡아낼 수 없을 것 같다.	구성원들이 컨텍스트를 알기 어렵다고 생각합니다	- 신규 입사자의 경우 코드를 작성할때 팀에 코드 스타일에 적응하는데 더디다?		같이 일하는 동료의 업무를 알기 어렵고 버그가 발생할 확률이 더 올라갈 것 같습니다.		개인의 부담감이 올라간다. 실수를 발견하는 시점이 늦어진다. 문제가 더 나중에 발견된다. 다른 사람과 나의 코드르 합치는 과정이 늦어진다. 서로 다른 팀원의 전문성을 배우는게 쉽지 않다 (최종 결과물 코드만 보게 되므로)	피드백없이 코드를 병합해야한다. 그대로 배포가나가서 터졌을때 어떤 커밋이 문제인지 정확한 파악이 어렵다
12
13	코드 리뷰를 도입하기 위한 노력은 무엇이 있을까?	- 코드 리뷰 문화 도입을 제안하기 - 모르는 분들에게 구체적으로 설명하기 - 부정적인 분들에게 문화의 장점 전파하기 - 프로토타입을 만들어 구체적인 예시를 보여주기 - 기존 프로세스와의 괴리감을 줄이기 위한 방법 모색하기 - 리뷰어와 승인자를 선택하는 기준 정하기		본인의 코드부터 리뷰를 부탁한다. 안하던 사람은 본인의 코드 리뷰를 꺼려할 수도 있기 때문	- 짝 프로그래밍부터 도입을 할 것 같아요 첫번째 다녔던 회사에서 코드 리뷰 도입을 했었는데요. 처음부터 코드 리뷰 하기가 어려워서 화면을 공유하여 자신이 짠 코드를 리뷰하는 시간을 가지거나, 같이 구현하는 시간을 가졌어요. 이렇게 지내다보니 시간이 지나 서로간의 코드가 부담이 안되는 시간이 와서 그때부터 온라인 코드 리뷰를 하게 되었어요.		- 리뷰를 위한 가이드라인 및 팀내 코딩 컨벤션 정의, 코드리뷰를 업무 프로세스에 포함시키기 위한 강제화? 시간 확보?	코드 리뷰가 공개적인 자리에서 자신의 실력이 평가되는 두려운 시간이 아니라, 서로 함께 더 좋은 코드를 위해 생각을 공유하는 장으로 다가가보면 좋을 것 같습니다	팀의 코드 컨벤션을 함께 정의하고, 코드리뷰의 장점과 절차에 대해 논의해보면 좋을 것 같습니다.		상호 피드백을 통해 보람을 느끼는 경험을 만들어보는게 일단 중요할 것 같아요. 코드 리뷰는 좋으니까 합시다~! 하면 오히려 반감을 살수도 있을것 같아요. 짝 프로그래밍, 코드 리뷰라는 방법을 먼저 제안하는게 아니라 지금 우리가 겪고 있는 고통 포인트가 무엇이 있는지 이야기 나눠보고 그걸 개선하기 위해 우리가 무엇을 해볼 수 있을지 이야기 나누면서 짝프로그래밍, 코드 리뷰와 비슷한 형태의 무언가 액션 플랜을 뽑아볼것 같아요!	서로 기분이 상하지 않게 하는 피드백은 노력을 기울여야하는 부분인것 같다
14					> 좋은 생각이네요 전 이런 생각을 아예 못해봤는데 ㅎㅎ
15	코드 리뷰 문화를 도입할 때 어려운 점은 무엇인가?	- 코드 리뷰 문화를 이끌 리더의 부재 - 자신의 코드에 대한 자신감 결여(실력에 대한 치부) - 변화나 새로운 경험에 대한 불안감 - 학습이나 성장에 대한 열정 결여(프로페셔널 마인드 부재) - 팀원들을 설득시킬 방법에 대한 고민 - 당연히 있어야하는 과정이라는 인식 주입		같이 하는 분들에게 장점을 설명하고 설득하기	저는 처음에 가장 어려웠던 것은, 저의 코드를 보여주는 것과, 저의 코드가 비난 당할 때 이를 해결해나아가는 과정이 어려웠어요 ㅠ		시간확보, 구성원들의 합의를 이끌어 내는것, 팀내 문화로 계속해서 지켜내는 것	코드에 대해 서로 의견을 주고 받아야 하다보니 내성적인 분들이나 지적을 받는 것을 두려워하시는 분들에게는 어렵지 않을까 생각합니다		개발 일정이 촉박할떄	설득하는 과정. 그리고 규칙을 만들고 지켜 나가는 과정을 지속하는 것	개발일정이나 테스트코드는 비즈니스를 하기위함이 아니라고 여기는 사람들을 설득하기
16
17	그렇다면 코드 리뷰 문화를 위한 룰(규칙)을 만들 때 고려사항은 무엇이 있을까?	- 회사의 경영(재정) 상황 - 팀의 구조(형태) 및 규모 그리고 팀원들의 성향 - 사내 개발 프로세스 및 룰(규칙, 가이드라인) - 요청의 성격(hotfix와 같은 장애 긴급 대응 등) - 사용가능한 도구 종류 및 제한(금전적, 보편적 측면 등) - 스타일의 기준(대체 어디까지가 스타일인가?) - 지향하는 코드 리뷰의 절차		이유를 함께 적기, 하나의 PR에 두 명이상의 리뷰어를 두기(문제를 확실하게 잡고, 하나의 생각에 고착화되지 않기 위해)	- LGTM 난무하지 말 것. - 칭찬을 섞어서 리뷰해줄 것 - PR Approve 인원은 xx명 이상으로		- 피드백 할때 적절한 톤 (자칫하면 비난의 어조로 들릴 수 있기 때문에), - 리뷰범위	코드를 코드로만 평가하되 코드로 사람을 평가하지는 않아야 될 것 같습니다	동료를 깎아 내리기 위해 진행하는 활동이 아니라 같은 목표를 가지고 더 좋은 코드를 만들기 위해 하는 활동이므로 언어를 순화해서 서로 감정이 상하지 않도록 하는 것이 좋을 것 같습니다.	코드만 객관적으로 판단하기	리뷰 문화를 만들고자 하는 나에 대한 호감과 신뢰 팀원들이 자신의 부족한 모습을 보여줘도 괜찮다는 심리적 안정감 사람에 대한 지적이 아니라, 코드에 대한 피드백	코드리뷰 규칙 반드시 고칠점 코멘트 등 구분하기
18
19	이런 노력도 하면 어떨까요?								코드리뷰 외에 정적분석툴 도입 등 코드 품질을 높이기 위한 활동을 같이 할 수 있으면 좋을 것 같습니다.		- 다른 사람의 코드 작성을 도와주는 경험(!?) - 다른 사람이 겪는 문제 해결에 도움 주기	부족한점이 있다면 예시코드를 작성해주기
20
21	코드 리뷰를 받는 입장에서 느낀 불편한 점을 이야기 해보자!	일정에 쫓겨 리뷰 반영 시간 부족 > 배포 일정이 코앞인데 리뷰 내용이 아키텍처, 클래스 구조 수정처럼 작업량이 많은 경우 리뷰어들의 낮은 참여도로 인해 공백 시간 발생 > 알람 시스템 부재 또는 개인적으로 요청 받은 지 모르는 경우 > 본인들의 개발 일정이 급함 > QA 또는 배포 일정이 많이 남은 경우 > 리뷰 요청 받은 작업 자체가 우선순위나 중요도가 낮은 경우 불쾌한 말투로 공격적인 리뷰를 받는 경우		리뷰해주시는 분의 일정이 생기면 기다리는 시간이 증가한다	팀 안에서 저만 프로그래밍 언어가 달라요.		- 적절한 수준의 pr로 쪼개기 - 부담감	PR 요청부터 리뷰를 받기까지의 시간이 길어진다면 중간에 시간을 어떻게 활용해야할지 조금 고민이 됩니다	불편한 점은 아니지만, 연차가 많이 차이나는 선배 개발자분들의 생각에 맞춰서 개발을 진행하게 되는 것 같습니다.	- PR 크기가 커서 중간중간에도 리뷰를 받고 싶을때 - 설계단계에서부터 리뷰가 진행되면 좋을것같다	좋은 PR을 보내기 위해서 PR 보내기 까지의 과정이 부담이 될수도 있다는것! 사실 짝 프로그래밍으로 코드를 작업하고 PR을 보내면 훨씬 마음이 편한데, 혼자서 작업하고 PR보낼때는 늘 어느정도의 부담을 느끼는것 같아요	중요하지 않은부분이나 커밋의 중점사안이 아닌것에 지나치게 많은 시간을 쏟게되는 피드백	불편하다기보다, 잘 보여야겠다는 생각이 많이 들어서 PR 하나 생성하는데 시간이 오래 걸렸어요 (욕 먹기 싫어서)
22
23	코드 리뷰를 하는 입장에서 느낀 불편한 점을 이야기 해보자!	개발 업무와 동시에 다른 팀원의 코드 리뷰를 하는 것이 일정 조율이 어려움 관심이 없거나 잘 알지 못하는 도메인 지식이 필요 교육과 다르게 실무에서는 리뷰할 양이 너무 방대함 연관된 PR을 모두 확인해야 하는 번거로움		PR크기가 너무 크거나, 자신이 개발하던 것과 다를 때 파악하는데 시간이 걸린다.	도메인이 다른 경우, 코드리뷰 하기 가장 어려운 것 같아요. 도메인 지식에 대한 이해가 서로 다르다는 점이 가장 큰 것 같네요.		- pr 크기가 너무 클때 - 기반 도메인 지식이 없을때 ㅠㅠ	이전에 언급했던 문제점들이 다시 나타나는 경우를 보면 같은 말을 반복해야해서 다소 피로해지는 것 같아요	코드리뷰할 양이 많은 경우 코드를 꼼꼼하게 리뷰하기가 어려운 것 같습니다.	해당 도메인 지식이 부족할떄	한번에 리뷰할 양이 많으면, 막연한 점이 있는것 같아요	한번에 너무 많은 변경사항을 하나의 커밋으로 처리할때	피드백의 의도를 리뷰이의 시각에 맞춰서 피드백 하기
24								ㄴ 공감합니다! 반복되는 피드백은 힘든 것 같아요 ㅠ
25	바른 코드 리뷰 문화를 위해 해야 각자의 위치에서 노력하면 좋은 점	리뷰 요청자 리뷰를 받고 싶은 내용을 정리하여 설명, 언급하기 모르는 부분은 바로 질문하기 다른 분들과 의견이 다른 부분은 정확하게 의사 표현하기 리뷰 요청을 하기 전에 검토하기 > 테스트 케이스 검토하기 리뷰어, 승인자는 내가 아닌 코드를 이야기하고 있음을 이해하기 꼭 코드 리뷰가 아니어도 되는 것은 다른 방법으로 도움 받기 > 설계는 작업 시작 전 리뷰를 요청하기 > 필요한 사전 지식은 미리 확인하기 > 페어 프로그래밍과 같은 방식의 코드 리뷰도 요청해보기 작업의 양이 많다면 미리 리뷰를 요청하기 리뷰어 다음 사항 확인하기 > 요구 사항을 얼만큼 잘 구현했는가? 버그가 있지는 않은가? > 설계된 아키텍처는 요구사항 구현에 있어 적합한가? > 클래스 구조나 코드를 더 쉬운 형태로 작성할 수는 없는가? > 기존에 다른 기능에 영향을 주지는 않는가?(사이드 이펙트, 성능 이슈 등) > 논리적인 측면에서의 코드나 모듈의 중복은 없는가? > 컨벤션 및 코드 가이드를 잘 따르고 있는가? > 주석은 얼마나 적합한가? 코드로 대체할 수는 없는가? 리뷰한 개수가 너무 많아 요청자가 반영하기 어렵지 않은지 살펴보기 리뷰이에 대한 비난, 비하 발언 삼가고 칭찬과 질문 형태로 리뷰를 작성하기 > 사람이 아닌 코드에 대해서만 이야기 하기 완벽한 코드로 만들려 욕심내지 말고 지금보다 개선한다는 것을 목표로 하기 추상적인 설명보다는 구체적으로 설명하기 가능하면 내용을 뒷받침할 문서, 첨부 자료 등을 공유하기 최종 승인자 (또는 담당자) 1명 이상의 리뷰어의 동의(LGTM)를 받았는 지 확인하기 기능적 요구사항이 잘 지켜졌는 지 확인하기 보안 이슈가 있는지 확인하기			배우고자하는 마음으로 코드 리뷰를 받아보자. 자신의 생각을 아낌없이 말하자.		리뷰어 > 서로 긴 논쟁으로 감정이 격양? 또는 상한 상태라면 크리티컬한 문제가 아니라면 그냥 승인하자 만약 승인 못하겠으면 다른 리뷰어에게 할당 리뷰 요청자 > 서로 긴 논쟁으로 감정이 격양? 또는 상한 상태라면 만나서 얘기하면 조금 낫지 않을까?		코드 리뷰어 입장에서 코드 리뷰하기가 편하도록 리뷰를 요청할 때 설명을 자세하게 하고, 어떤 이유로 개발했는지 잘 적어주면 좋을 것 같습니다.		코드 리뷰가 잘 안되는 팀의 경우는 평소에도 서로 피드백을 주고 받는 경험이 많이 없을것 같아요. 평소에 서로 어떻게 피드백을 주고 받는게 의미있는 경험이 될지 자체를 이야기 해보는것도 중요할것 같네요 :) 최대한 코드를 다 작성하고 피드백을 주고 받는게 아닌, 작은 단위로 '과정'에서 피드백 주고 받기	너무 모든것을 완벽하게 하려 하지 않기, 아무리 뛰어나도 특정 개인만 항상 옳진 않다	리뷰이 자신의 코드가 자신이 없더라도 부끄러워하지 말자. 모르는 것은 죄가 아니다 리뷰어 모를 수도 있다. 비즈니스 로직상 버그나 오류가 아니라면 조금은 러프하게 피드백해도 괜찮을 것 같다.
26
27	이런 노력도 해보자	모듈, 패키지, 서브 도메인 등의 오너 선정처럼 어떤 기준을 정해 리뷰어, 최종 승인자를 정해보자 코드 리뷰를 위한 시간을 확보하자 협의를 통해 PR 템플릿을 만들어 일관된 내용으로 요청을 보내보자 빠른 피드백을 위해 리뷰어의 피드백 시간 제한을 설정해보자 코드 라인 수, CL 파일 수 등에 제한을 두어 리뷰 요청의 크기를 줄여보자 레이블, 태그 등을 활용해 요청의 성격을 분류해보자 브랜치 전략, 포매터, 린터 등과 같은 도구를 적극 활용해보자 리뷰의 범위, 리뷰 반영 수준을 우리에게 맞게 정해보자 많은 룰을 만들고, 모두 지키기 어렵다면 반대로 룰을 최소한으로 줄여보자 올바른 테스트 코드 작성법 전파 등 코드 리뷰 사전 작업에도 노력을 기울여보자									취업, 이직 전에 회사의 문화를 미리 알아보기!		좋은 코드 리뷰 문화를 가진 곳으로 이직!
28
29	[마지막으로 코드 리뷰 문화를 되돌아보자]	모두가 같은 목적으로 같은 방향을 바라보고 있는 것이 맞는가? 코드 리뷰에 할애하는 시간 및 리소스를 줄이는 방법은 무엇이 있을까? > 설계 리뷰를 앞당겨 사전에 별도로 진행하는 건 어떨까? > 코드 리뷰 외에 서로의 도메인 지식 및 기술적 지식을 공유할 수 있는 방법은 어떤 것들이 있을까? 우리는 서로 간의 예의를 충분히 지키고 있을까? 성과가 없는 코드 리뷰는 의미가 있을까? > 코드 리뷰의 성과로는 어떤 것들이 있을까?
30
31	정리	코드 리뷰 문화 또한 성과가 없다면 의미 없는 프로세스일 뿐이다! 집착하지 말자! > 코드 리뷰 문화 도입과 개선의 궁극적인 목표는 현재보다 나은 프로덕션을 효율적으로 개발하는 것! > 바로 완벽해지려 하지 말고, 단지 현재보다 나은 아키텍처, 코드를 위해 노력하자! 그가 아닌 그의 코드를 논하자! 상대도 내가 아닌 나의 코드를 이야기 할 것이다! 우리의 직업은 개발자이지 리뷰어가 아니다! 모두에게 감사의 마음을 갖도록하자 세상에는 다양한 사람이 있다 서로 배려하며 존중하자!
32
33	결론	코드 리뷰 문화의 형태가 똑같은 곳은 어디에도 없다! 우리만의 문화를 만들어가자!
34	피드백
35	수업을 듣기 전에 기대한 것은 어떤 것이었나요? 수업을 들은 후 기대한 바가 충족된것 같나요?			실제 사례를 듣고싶었습니다. 네 충족되었습니다!	코드 리뷰 문화에 대해 좋은점과 어려운점을 공유할 수 있는 시간을 가질 수 있어서 너무 좋았습니다. 코드 리뷰에 대해 항상 기준점이 있다고 생각했는데, 그게 아니라 코드 리뷰 문화는 같이 만들어가야한다는 것을 깨닫게 되었습니다.	코드리뷰 문화가 전혀 없는 곳에 코드리뷰 문화를 만드는 것이었는데 많은 도움이 되었습니다.	코드리뷰 팀내 도입을 고민중인데 어떻게 시작할지 막막했는데 도움이 되었습니다. 또한 다른 사람들의 의견도 들을 수 있어서 너무 좋았습니다	아직 회사에 코드 리뷰 문화가 없다보니(사실 생길 뻔했다가 없어진...) 어떻게 도입해보면 좋을지에 대한 고민을 조금이나마 해소할 수 있기를 기대했고, 덕분에 좋은 인사이트를 많이 얻을 수 있었습니다		코드 리뷰의 이상적인 방향에 대해 배우기 - 수업 들은 후에 어떻게 하면 좋겠다라는 생각이 많이 들어서 좋았습니다!
36	강의를 듣고 배운 내용을 빠른 시일내에 적용해보고 싶은 곳이 있나요? 아니면 최근에 했던 시행착오를 다르게 해결해보고 싶은게 있을까요?			현재 진행하는 사이드 프로젝트에 적용해보고 싶습니다. 오늘 수업 내용을 바탕으로 팀원을 설득해보려 합니다	아키텍처에 대한 내용을 빠른 시일내에 적용해보고 싶네요.	바로 적용까지는 아니더라도 팀원들과 오늘 들은 발표 내용에 대해 얘기를 나눠보고 싶습니다.	오늘 강의에서 나온 내용을 토대로 팀원들과 이야기를 시작해 볼 수 있을거 같아요	처음부터 모든 구성원이 함께 리뷰에 참여하는 것은 무리겠지만, 먼저 현재 진행 중인 프로젝트의 구성원들과 조금씩이라도 코드에 대한 이야기를 나눠보고자 합니다	기존에 정착되어있는 코드리뷰 문화가 있어 강의에서 배운 내용을 조금씩 적용해보도록 하겠습니다.	바로 적용은 힘들더라도 조금씩 적용하면 좋을 것 같습니다 !
37	기타 피드백 (위 2 질문 외에 다른 피드백을 주세요) - 난이도 - 시간 분배 - 설명 등			난이도 적당했습니다. 시간분배도 적당했습니다. 음.. 피드백을 통해 성장하는 것을 알기 때문에 피드백을 드리고 싶은데, 너무 잘해주셔서 드릴 피드백이 없네요. 고생하셨습니다!	- 난이도 : 난이도 적당했어요! 코드 리뷰 문화에 대해서 많은 도움이 되었습니다 ^^ - 시간 분배 : 티키타카 완벽 - 설명 : 굳굳	난이도는 실무자라면 누구나 이해하기 편할 정도였다고 생각합니다.	- 난이도 : 무난했습니다 - 시간 분배: 적당했습니다. - 설명: 직접 경험담을 위주로 얘기해주셔서 좋았습니다. 온라인으로 진행하시다보니 듣는 사람의 즉각적인 피드백이 없어 조금 힘드셨을거 같아요 ㅠ	듣는 내내 정말 편안했고 시간 분배도 적절히 해주셔서 전혀 지루하지 않았습니다	공감할 수 있는 내용 위주로 진행해 주셔서 난이도는 어렵지 않았고, 다른 분들이 코드리뷰에 대해 어떻게 생각하시는지 알 수 있었습니다. 시간, 설명도 강의준비를 잘 해주셔서 적절하고 좋았습니다.	시간 분배도 적절하고 좋았습니다!	두 분의 경험을 섬세하게 정리하여 공유해주신 점이 너무 알차고 좋았어요. 그래서 이 경험들이 어떻게 하면 수강생 분들에게 더 의미있게 활용될 수 있을까를 고민하면서 참여했었는데요. 제가 생각했을 때는 두 분의 경험을 통해서 정리한 내용이, 정리한 내용으로 주시는게 아니라 코드리뷰의 피드백처럼, 다른 분들의 경험에 대한 피드백 관점으로 공유되면 더 좋을것 같다는 생각이 들더라구요. 지금 참여해주신 분들이 대부분 현업에 계시는데, 먼저 각자 현업에서 코드 리뷰 문화에 대한 만족도는 어느 정도인지, 만약 충분히 만족하지 못한다면 내가 아쉬운 부분은 어떤 부분인지를 남겨보는거에요. 그리고 아쉬운 부분이 비슷한 관심사로 묶일 수 있다면 그룹으로 이야기를 나눠보면서, 공감대를 형성하고, 각 케이스에 대한 이야기에 두 분의 경험을 바탕으로 피드백 주시고 어떻게 개선할 수 있을지를 나눠 봤으면 어떨까 싶어요 ㅎㅎ 그러면 교육이 끝나고, 내 상황에서 두 분의 피드백을 바탕으로 이런 부분을 개선해보거나 시도해볼 수 있지 않을까? 하는 그림을 머릿속에 더 구체적으로 그릴 수 있지 않을까 싶습니다!
38	질문이 있다면 남겨주세요 :)				일정이 있어 나왔지만, 팀원이 두명인 상태에서 코드리뷰를 어떻게 해나아갈 것인가에 대해 의견을 듣고 싶습니다.		- PR의 크기를 보통 라인수로 제한 하시나요? - 말씀해주신거 처럼 여러 pr이 서로 연관이 있을때는 어떻게 요청 또는 리뷰 하나요? (PR2가 PR1코드 기반으로 생성)
39					> 음 코드 리뷰를 자유롭게 할 수 있는 환경이라고 가정하면 인원이 적으니 페어 프로그래밍을 통해서 코드 리뷰 문화에 대한 서로의 의견을 공유하고 지식 등을 주고 받아가면서 문화를 만들어가도 좋을 것 같습니다 2명 밖에 되지 않아 오너 등을 나누거나 리뷰 파트를 나누는 것보다는 자유롭게 지속적으로 상호작용이 되는 형태로 진행하면 어떨까 싶습니다 ㅎㅎ		> 저희 회사 같은 경우에는 논리적인 기능 구현을 위주로 PR을 나누고 있긴합니다! 이 기능을 최대한 작게 자르는 형태로 크기를 조율하고 있네요 > 저희는 이렇게 여러개의 PR이 순차적을 그리고 한 번에 합쳐져야 한다면 해당 PR들만을 위한 브랜치를 별도로 따서 거기에 순서대로 PR을 날리는 형태로 진행하고 있습니다
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100