Code Review Conversations
코드 리뷰에서 지적하고 받아들일 수 있다
영어 · C1 · 대화 · 3:20
이 회차를 마치면: 코드 리뷰에서 지적하고 받아들일 수 있다
꼭 외울 표현
Would it be clearer if we extracted that logic?
그 로직을 뽑아내면 더 명확해질까요?
코드 구조를 제안할 때
What's the intent behind this check?
이 검사의 의도는 무엇인가요?
코드 작성 의도를 물을 때
Good catch. I'll refactor that.
잘 찾았네요. 리팩터링하겠습니다.
지적을 받아들이고 수정 의지를 보일 때
대본과 번역
- N
안녕하세요. 오늘 수업의 목표입니다.
안녕하세요. 오늘 수업의 목표입니다.
- N
코드 리뷰에서 지적하고 받아들일 수 있다.
코드 리뷰에서 지적하고 받아들일 수 있다.
- N
이제 두 사람이 코드 리뷰 미팅을 시작합니다.
이제 두 사람이 코드 리뷰 미팅을 시작합니다.
- A
Thanks for pairing on this. I looked at your PR and found one thing.
함께 봐줘서 고마워요. 풀 리퀘스트를 봤는데 한 가지 발견했어요.
- B
Sure. Did you find a bug?
물론이죠. 버그를 찾았나요?
- A
Not really. I think the readability suffers because the function does too much.
꼭 버그는 아니에요. 함수가 너무 많은 일을 해서 가독성이 떨어진다고 생각해요.
- B
I see. I'm boring when I review too many files.
알겠어요. 파일을 너무 많이 리뷰하면 저는 지루해요.
- A
That happens to me too, but I'm bored when the task is too repetitive.
저도 그래요, 하지만 작업이 너무 반복적일 때는 지루함을 느껴요.
- B
I get it. I'm bored when the task is too repetitive.
이해했어요. 작업이 너무 반복적일 때는 지루함을 느껴요.
- A
Would it be clearer if we extracted that logic into a separate function?
그 로직을 별도 함수로 뽑아내면 더 명확해질까요?
- B
I see. I was worried about reading the whole thing again, especially around the edge case.
알겠어요. 특히 예외 상황 주변을 전체를 다시 읽는 게 걱정됐어요.
- A
That makes sense. But what's the intent behind this check here?
이해가 돼요. 그런데 이 검사의 의도는 무엇인가요?
- B
It guards an edge case when the input is empty, so the naming should reflect that intent.
입력이 비어 있을 때 예외 상황을 막아주는 거라, 명명도 그 의도를 반영해야 해요.
- A
The test coverage also dropped here. Should we add one?
여기 테스트 범위도 떨어졌어요. 하나 추가할까요?
- B
Good idea. I'll add a test for the edge case.
좋은 생각이에요. 예외 상황에 대한 테스트를 추가할게요.
- A
One nitpick: the variable name is a bit vague.
사소한 지적 하나: 변수 이름이 좀 모호해요.
- B
You mean dataList?
dataList 말인가요?
- A
Yes. A name like validatedRecords would be clearer.
맞아요. validatedRecords 같은 이름이 더 명확할 거예요.
- B
I see. That also helps the intent stand out.
알겠어요. 그러면 의도도 더 잘 드러나네요.
- A
Thanks for being open to feedback. I appreciate it.
피드백에 열려 있어 줘서 고마워요. 정말 감사해요.
- B
Not at all. I want this to be solid.
천만에요. 이 코드가 견고했으면 좋겠어요.
- A
Let me leave one more comment. Would it be clearer if we extracted that logic into a helper?
댓글 하나 더 남길게요. 그 로직을 헬퍼로 뽑아내면 더 명확해질까요?
- B
Good catch. I'll refactor that.
잘 찾았네요. 리팩터링하겠습니다.
- N
이제 복습 시간입니다. 청크를 천천히 다시 듣고, 새 문장에서 써 봅니다.
이제 복습 시간입니다. 청크를 천천히 다시 듣고, 새 문장에서 써 봅니다.
- A
Would it be clearer if we extracted that logic into a separate function?
그 로직을 별도 함수로 뽑아내면 더 명확해질까요?
- B
In my team, we ask: would it be clearer if we extracted that logic before the meeting?
우리 팀에서는 회의 전에 그 로직을 뽑아내면 더 명확해질지 물어봐요.
- A
What's the intent behind this check?
이 검사의 의도는 무엇인가요?
- B
Before I merge, I always ask: what's the intent behind this check?
병합하기 전에 항상 이 검사의 의도가 무엇인지 물어봐요.
- A
Good catch. I'll refactor that.
잘 찾았네요. 리팩터링하겠습니다.
- B
When a reviewer finds a real issue, I say: good catch. I'll refactor that.
리뷰어가 실제 문제를 찾으면 이렇게 말해요: 잘 찾았네요. 리팩터링하겠습니다.
- N
이제 여러분의 차례입니다. 아래 질문을 듣고 답을 말해 보세요.
이제 여러분의 차례입니다. 아래 질문을 듣고 답을 말해 보세요.
- A
A reviewer says the naming is vague and suggests a better name. How do you respond?
리뷰어가 명명이 모호하다고 말하며 더 나은 이름을 제안합니다. 어떻게 답하나요?
- A
For example, you can say: good catch. I'll refactor that.
예를 들면 이렇게 말할 수 있어요: 잘 찾았네요. 리팩터링하겠습니다.
- B
You can also add why. I'll rename it to validatedRecords.
이유도 덧붙일 수 있어요. validatedRecords 로 이름을 바꿀게요.
- N
오늘 목표를 확인합시다. 코드 리뷰에서 지적하고 받아들일 수 있다.
오늘 목표를 확인합시다. 코드 리뷰에서 지적하고 받아들일 수 있다.
- N
세 청크를 다시 들어 봅시다.
세 청크를 다시 들어 봅시다.
- A
Would it be clearer if we extracted that logic?
그 로직을 뽑아내면 더 명확해질까요?
- B
What's the intent behind this check?
이 검사의 의도는 무엇인가요?
- A
Good catch. I'll refactor that.
잘 찾았네요. 리팩터링하겠습니다.
- B
And remember: thanks for being open to feedback.
그리고 기억하세요: 피드백에 열려 있어줘서 고마워요.
- N
오늘도 수고하셨습니다. 다음 시간에 만나요.
오늘도 수고하셨습니다. 다음 시간에 만나요.
이 회차의 낱말
| 표현 | 읽기 | 뜻 |
|---|---|---|
| readability | 레드어빌리티 | 코드가 얼마나 읽기 쉬운지를 나타내는 가독성 |
| refactor | 리팩터 | 코드의 외부 동작은 유지하면서 내부 구조를 다시 쓰다, 리팩터링하다 |
| edge case | 에지 케이스 | 일반적인 상황이 아니라 드물게 일어나는 예외 상황 |
| intent | 인텐트 | 코드를 작성한 이유나 목적, 의도 |
| naming | 네이밍 | 변수나 함수의 이름을 짓는 명명 방식 |
| test coverage | 테스트 커버리지 | 테스트가 코드 중 얼마나 많은 부분을 점검하는지, 테스트 범위 |
| nitpick | 닛픽 | 크게 중요하지는 않지만 눈에 걸리는 사소한 지적 |