200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
•
5 gefällt mir•1,619 views
200820 NAVER TECH CONCERT - 오두경 Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
Ähnlich wie 200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte) (20)
Mehr von NAVER Engineering
Mehr von NAVER Engineering (20)
200820 NAVER TECH CONCERT 15_Code Review is Horse(코드리뷰는 말이야)(feat.Latte)
- 1. 1 / 53
- 2. codeReview is Horse 코드리뷰란 말이야 요즘엔 리뷰하기 참 좋아졌지.. NAVER/오두경 feat.Latte ☕ 2 / 53
- 3. 오늘은 코드 리뷰의 단계를 더 좋은 코드를 만들 수 있는 코드 리뷰를 할 수 있는 방법들 리뷰어/리뷰이 모두 즐겁게 코드 리뷰를 할 수 있는 소소한 팁 에 대해 이야기 해보려고 합니다 3 / 53
- 4. 코드 리뷰? 사전적 정의 여러 사람들이 코드를 읽고 검증하여 소프트웨어 품질을 높이는 것 간단하게 말하면, 코드에 대한 의견을 주고 받는 것 효과로는 버그 감소, 코드 퀄리티 향상 등 4 / 53
- 5. 용어 정의 리뷰어 - 작성한 코드를 보고 의견을 주는 사람 리뷰이 - 코드를 작성하고 다른 사람에게 의견을 받는 사람 5 / 53
- 6. 네이버 개발자들은 코드리뷰를 어느정도 하고 있나요? 2020.07 사내 개발자 대상 설문조사 결과 약 95%의 개발자들이 코드리뷰를 하고 있습니다 6 / 53
- 7. 코드리뷰 해봤어? 해봤어??? 그럼, 어디까지? 7 / 53
- 8. 코드 리뷰 단계 8 / 53
- 9. 0단계: 한 눈에 오류가 보이는가 우리가 제일 많이하고 쉽게 할 수 있는 리뷰 공백 오타 줄바꿈 변수명 코드 컨벤션 9 / 53
- 10. 0 단계는 여러가지 도구를 이용해 스킵할 수 있습니다 🙌 10 / 53
- 11. 코드 리뷰를 도와 주는 도구들 자동화 에디터에 저장 시 포매팅 설정 prettier Vs Code 오타를 방지 에디터 플러그인 Code Spell Checker Lint / feat.Latte ☕ eslint JSLint JSHint 커밋, push등 git 훅을 설정할 수 있는 라이브러리 fix lint, prettier, 커밋메시지 컨벤션 적용 husky 11 / 53
- 12. 코드 리뷰를 도와 주는 도구들 문서화 feat. 인플루언서 검색 컨벤션 문서 정리 12 / 53
- 13. 코드를 읽고 하는 리뷰 13 / 53
- 14. 1단계: 기능 구현이 잘되었는가 주어진 스펙이 구현이 잘됬는가? 스펙에 ~라는 부분이 있는데 이 부분이 기능에 누락된 것 같습니다 14 / 53
- 15. 1단계: 기능 구현이 잘되었는가 버그 찾기 나아가 디버깅 하기 B페이지에서도 이 함수를 호출하고 있는데요 현재 변경으로 인해 동작하지 않네요 인자가 잘못 넘어오는 것 같습니다 코드상 보이는 명백한 버그 찾기 vs 실행 시킨 후 버그 찾기 15 / 53
- 16. 2단계: 확장성이 좋은 코드인가 반복을 줄일 수 있는가? 자주 쓰는 부분이니 공통 유틸 함수로 만드는게 좋을 것 같습니다 재사용이 가능한 함수인가? number|string 모두 받게 하면 A에서도 쓸 수 있을 것 같습니다 불필요한 코드가 있는가 Z 기능을 쓰기 위해 A함수를 불러 불필요한 분기가 많은데요 A함수보다에서 가 기능을 분리해 B함수를 만들고 A,C에서 공통으로 쓰게 하면될 것 같습니다 16 / 53
- 17. 2단계: 이 좋은 코드인가확장성 17 / 53
- 18. 3단계: 유지 보수가 좋은 코드인가? 이 좋은가? 요약 두 개의 변수로 변경탐지를 하면서 애니메이션 show, hide처리를 하는데 헷갈린다 변경탐지 변수는 하나로 만들어 가독성을 높이자 가독성 18 / 53
- 19. 3단계: 유지 보수가 좋은 코드인가? 적으로 개선할 수 없을까? 요약 카테고리가 달라져도 같은 데이터니 매번 요청하지말고 데이터니 캐싱해서 쓰자 성능 19 / 53
- 20. 3단계: 유지 보수가 좋은 코드인가? 성능 vs 가독성 [1, 2, 3, 4].filter((v) => v > 2).map((v) => v * 2); [1, 2, 3, 4].reduce((acc, v) => { if (v > 2) { acc.push(v * 2); } return acc; }, []); 20 / 53
- 21. 3단계: 유지 보수가 좋은 코드인가? 을 모두 개선시킬 수 있는 방법은 없을까? 요약 가독성 데이터 구조가 배열이다보니 참조하는 곳에서 어떤 데이터인지 눈에 잘 안보인다 성능 데이터 조회/수정 시 매번 배열 순회하여 인덱스를 찾는 것도 불필요해보인다 가독성과 성능 21 / 53
- 22. 코드 리뷰를 단계별로 세분화 해서 확인해봤습니다 현재 나는 리뷰어로서 코드리뷰를 몇 단계까지 할 수 있을까요? 현재 나의 코드는 리뷰이로서 몇 단계의 리뷰를 받을 수 있을까요? 22 / 53
- 23. 더 높은 단계의 코드 리뷰를 받아봅시다 내 코드 이해시키기 23 / 53
- 24. 코드 단위를 작게하라 (한번쯤은 봤을 이야기) 리뷰하기 어려워짐 리팩토링을 기약하고 머지될 수 있음 리뷰어가 diff 를 열어보고, 읽기도 전에 지칠 수 있음 코드 단위가 크면 코드 전체적으로 리뷰를 받을 수 있음 (오타까지!) 너무 많은 리뷰가 있을 수 있음 코드 단위가 작으면 24 / 53
- 25. 작은 단위, 어떻게 하죠? 신입에게 작은 단위는 넘나 어려운것 😭 개발을 해봐야 이걸 나눴어야했나 하는 자괴감이 들어 25 / 53
- 26. 작은 단위, 어떻게 하죠? 처음부터 하긴 당연히 어렵습니다 코드 단위는 개발자가 느끼는 주관적인 영역이기 때문에 작은 단위에 대해 객관적으로 정할 수 없기도 합니다 하지만 불변의 진리 작은거 >>>>>>>>>>>>>> 큰거 26 / 53
- 27. 작은 단위, 어떻게 하죠? git diff 적극 활용하기 불필요한 변경은 diff 에 잡히지 않도록 함 공백, 에디터 설정에 의한 많은 파일 변경 eslint 도 불필요한 diff와 관련된 룰임comma-dangle 27 / 53
- 28. 작은 단위, 어떻게 하죠? diff 에 불필요한 내용이 들어가지 않도록 커밋 나누기 28 / 53
- 29. 작은 단위, 어떻게 하죠? 로직과 단순 파일이름 변경 삭제 커밋은 분리하기 29 / 53
- 30. 코드를 예상 가능 하게 하라 30 / 53
- 31. 예상가능한 코드? 커밋 잘 하기 커밋 메시지 잘 쓰기 기능과 연관된 커밋 메시지 버그 수정 -- const isShow = a !== b ++ const isShow = a === b 분기문 오류로 화면에 에러메시지 노출안되는 문제 수정 커밋메시지로 코드 수정 이유를 명확하게 하기 31 / 53
- 32. 예상가능한 코드? PR 잘 쓰기 프로젝트 관리방법은 팀마다 다를 수 있으나 코드 베이스로 문서를 볼 수 있는 곳은 PR(Pull Request) PR엔 코드를 이해하기 위한 모든 내용이 있으면 좋음 PR은 아무것도 모르는 사람이 본다고 생각하고 쓰기 32 / 53
- 33. 실제 어떻게 쓰고 있나요? 추가된 기능과 구현 방법 33 / 53
- 34. 실제 어떻게 쓰고 있나요? 버그 원인 34 / 53
- 35. 실제 어떻게 쓰고 있나요? 유관 부서(디자인,설계,서버)와 협의 된 내용 35 / 53
- 36. 실제 어떻게 쓰고 있나요? 코드 구현을 참고한 링크 36 / 53
- 37. 실제 어떻게 쓰고 있나요? 코드가 복잡하다면 가끔 그림도 그림 37 / 53
- 38. 코드에도 PR 에도 드러나지 않지만, 제가 고민했던 내용이 맞는지 리뷰 받고 싶어요 38 / 53
- 39. 리뷰 받고 싶은 포인트를 말하기 본인이 고민했던 내용을 어필하면 리뷰어는 그 내용을 중점적으로 리뷰할 수 있음 39 / 53
- 40. 남의 코드 이해하기 리뷰어의 노력에도 불구하고 코드가 이해가 가지 않는다면? 이해가 안가는 부분에 대한 명확한 근거 말하기 잘 이해가지 않는다면 오프라인 리뷰 요청하기 40 / 53
- 41. 리뷰어도 좋고 리뷰이도 좋은 코드 리뷰하기 리뷰이 편 41 / 53
- 42. 내 코드 ≠ 나 많은 리뷰 상처받지 말자 리뷰를 모두 반영하면 분명 성장해있을 것 42 / 53
- 43. 는 되지 말자 리뷰가 간단하더라도 리뷰어가 리뷰한 내용에 대한 근거는 있을 거다 찾아보자, 테스트해보자 핑거프린(세)스 이 부분, 이렇게 바꾸면 좋을 것 같습니다 what?? 무슨 말이죠 1. 현재 구현부와 리뷰의 내용의 차이점을 찾아본다 2. 검색/테스트해본다 3. 그래도 모르겠으면 리뷰를 반영하기 위한 노력을 어필하며 대답한다 43 / 53
- 44. 노력의 어필, 어떻게 하죠?? 리뷰 반영을 하기 위한 노력에 대한 내용이 없을 때 1,2,3 의 단계를 거치고도 다는 댓글의 내용의 차이 (리뷰어가 하루를 기다렸다고 가정) 이해 못했으니 해당 리뷰는 무시한다 노력에도 불구하고 이해를 못했지만 이를 숨기고 댓글을 단다 제 생각엔 이 리뷰를 반영해도 지금과 크게 달라지는게 없는 것 같습니다 이해 못했다고 댓글을 단다 제가 이 부분은 잘 이해가 되지 않습니다; 어떤 걸 말씀하시는 건지요? 44 / 53
- 45. 노력의 어필, 어떻게 하죠?? 리뷰 반영을 하기 위한 노력에 대한 내용이 있을 때 리뷰 주신 내용을 보고, 처음엔 잘 이해하지 못했는데요; 1,2,3 의 단계를 거치고도 다는 댓글의 내용의 차이 (리뷰어가 하루를 기다렸다고 가정) Case 검색 아마 이런 내용이 아니실까 하여 이렇게 찾아봤습니다 하지만 그래도 리뷰 내용을 정확하게 이해하지 못했습니다 이 부분을 리뷰 주신 게 맞을까요? Case 테스트 보여주신 코드로 이렇게 테스트 해봤는데 (코드, 테스트한 브랜치가 있으면 더 좋음) 오히려 흐름이 복잡해져서 코드의 흐름이 잘보이지 않게 되더라구여 그래서 현재 지금 안을 유지하면 좋을 것 같은데, 리뷰 주신 내용을 제가 제대로 반영한게 맞을까요? 45 / 53
- 46. 피드팩을 하자 리뷰 반영만 피드백이 아니다 좋은 리뷰는 이 부분을 알려줘서 좋았다! 라는 피드백을 주자 리뷰 반영 시 시간이 오래 걸릴 경우는 리뷰어에게 알려주자 리뷰어가 리뷰를 하고 기다릴 수도 있고, 서비스 일정 상 급한 기능일 수도 있다 내가 빨리 반영을 못하면 다른 사람이 작업을 해서 일정에 차질이 없게 하자 46 / 53
- 47. 리뷰어도 좋고 리뷰이도 좋은 코드리뷰하기 리뷰어 편 47 / 53
- 48. 좋은점은 좋다고 말하기 👏 👏 👏 👏 👏 나쁜거 10개고 좋은점 1개라도 꼭 말해주기 48 / 53
- 49. 반영해야 할 리뷰 vs 반영했으면 하는 리뷰 구분하기 버그 발생 할 개인 스타일 차이 하는 기능상 문제는 없으나 코드 개선이 필요, 작업이 큰 경우 할 하는 저는~ 이런 방식을 선호하긴 합니다 ㅎㅎ 코드 일관성, 유지관리 측면 일정이 빠듯한 경우 이 부분은 지금 반영하기에는 작업이 클 것 같아요 이번 배포 이후 개선하면 좋을 것 같습니다 49 / 53
- 50. 오늘은 코드 리뷰의 단계를 나눠봤고 더 높은 단계의 코드리뷰를 받을 수 있는 방법들 리뷰어/리뷰이 모두 즐겁게 코드리뷰 할 수 있는 소소한 팁 에 대해 이야기해봤습니다 50 / 53
- 51. 코드 품질을 측정하는 유일한 척도 = 분당 내지르는 WTF! 횟수 WTF(what the f*ck) - (순화해서) 어머!!!! 이게 뭐야!!! 이 발표를 듣고 리뷰어의 WTFs/minutes 가 줄었으면 좋겠습니다 51 / 53
- 52. 코드 리뷰를 통해 좋은 코드를 만들 수 있습니다 좋은 코드 리뷰는 리뷰어와 리뷰이 모두 성장 할 수 있습니다 52 / 53