코드 검토를 할 때 나는 독백을 실행하는 경향이 있으므로, 내가 읽고있는 것을 이해하기 때문에 많은 “Ok, 나는 그것이 무엇을하는지 알 수 있습니다. “좋아요 .. 그리고 그 작품은 두 가지 모두에 달려 있습니다.”

저는 이런 식으로 “우라라 너무 큽니다!”라고 생각하지 않습니다. 아주 지루한 코드 일 수도 있지만, 다른 사람이 실제로 여러분의 의견을 파싱하고 이해하는 것은 긍정적 인 피드백의 형태입니다. 피드백은 “이 코드는 의미가 있습니다.”라고 이해하지 못하는 부분이 생겼을 때 설명을 요청하고 이해할 때 “아, 알았어요”라고 외칩니다.

우리는 모두 다른 사람들이 코드를 이해하기를 원하기 때문에 이해의 단순한 전달이 다른 엔지니어에게 찬사를 보냅니다.

즉, 우수하거나 긍정적 인 특성을 가진 코드의 일부를 볼 경우 (심지어 지루한 사소한 코드라도 최소한의 형태이면 좋을 수 있음) 이러한 특성을 분명히 나타내는 경향이 있습니다. 큰!” “이것은 최소한의 구현이라고 생각합니다”또는 “좋아요,이 복잡한 알고리즘에는 많은 주석이 있습니다”, 코드의 속성에 중점을 두는 것은 본질적인 장점이나 나쁜 점이 아닙니다.

엔지니어가 아래를 보거나 받침대에 눌린 느낌이 들지 않도록하기 위해 코드 검토에서 코드에 “좋은 점”또는 “나쁜 점”을 표시 할 때마다 어떤 것이 나쁘다고 말하지 말고 오히려 원인과 결과에 대해 이야기하십시오. 그들의 코드.

“이 부분은 의미가 있습니다. 여기에는 마법의 숫자가 있습니다. 그 가치의 의미는 다음 엔지니어가 이것을 이해하지 못할 것입니다.”

“여기에 DI 컨테이너가 있어도 해당 저장소와의 연결이 느슨합니다.”

“여기에 정적 사전이 있는데, 여러 스레드가 해당 사전에 닿으면 일부 경쟁 조건이 발생할 수 있습니다.”

좋은 점이나 나쁜 점은 없지만 엔지니어가 변경 해야하는지 여부는 코드를 검토하는 엔지니어가 이해할 수 있습니다. 분명히 코드 검토를 yay 또는 nay로 끝내야하지만, 그 과정에서이 문장을 누적하면 nay가 “원합니다. 체크인하기 전에 고정 된 매직 넘버 “

답변