[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기Ahreum Kim2018. 11. 03 'FEConf 2018' 발표자료입니다.
---
처음으로 프론트엔드 프로젝트에 (유닛)테스트코드를 작성해보며 느낀 경험을 공유합니다. 어떤 관점으로 접근 했는지부터, 테스트코드 작성을 하며 만난 고민과 해결책은 어떤 방식으로 풀어 냈는지 코드와 함께 다뤄보려 합니다. 저는 테스트 숙련자가 아니지만, 저와 비슷한 위치에서 테스트에 입문하시려는 분들께 어떻게 테스트에 입문하고 코드를 작성했는지에 대해서 구체적인 경험을 공유하는 것도 의미있을 거라 생각했습니다. 제가 드릴 얘기들이 정답이 아닐 수 있지만, 더 좋은 방향을 고민하면서 같이 생각해볼 수 있다면 좋겠습니다.
Software engineer가 되기 위한 여정Aree Oh2020년 서울시에서 주최한 강소기업탐방 프로그램에서 발표한 자료 입니다.
학교를 졸업하고 software engineer로 취직을 하기까지의 여정을 다뤘습니다
1. 개발자가 나에게 맞을지 고민하기 위한 방법
2. 개발자로 취직하기 (이력서/면접 준비 팁)
3. 개발자로 취직한 후 우리가 하는 일
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)Kay KimNoel Llopis가 Montreal International Game Summit 2006에서 발표한 내용을 번역.
Agile 중에서 XP에 대해서 주로 다룸.
자세한 것은 http://betterways.tistory.com/51 참조.
Source: http://www.gamesfromwithin.com/articles/0611/000112.html
애자일의 모든것KH Park (박경훈)- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
손코딩뇌컴파일눈디버깅을 소개합니다.Kwangsung Ha"손코딩뇌컴파일눈디버깅" 모임을 소개합니다.
백문이 불여일런, 트라이얼앤에러(Trial and Error) 식의 몹쓸 교육을 받아 온 개발자들이 코딩하기 전에 신중하고 꼼꼼하게 생각해보기란 쉽지 않습니다.
개발 시간 중 디버깅 시간이 절반 이상을 차지하고 있는 실정에 버그를 줄이기 위해 TDD니 유닛테스트니 많은 방법들이 개발되고 있지만 가장 일차적으로 중요한 것은 개발자들이 꼼꼼히 따져보는 것이 아니겠는지요?
미국의 선진 SW회사들은 이미 화이트보드에 PS문제를 푸는 것을 인터뷰 방식으로 채택하고 있습니다. 이는 이와 같은 풀이 방식이 개발자들의 기본 역량을 측정하기에 알맞은 지표라는 것이고, 개발자들이 기본적으로 갖춰야 할 역량이기도 하다는 것 입니다.
또한 자신의 생각을 명확하게 정리하고 다른 사람이 이해할 수 있도록 전달하는 Communication Skill 도 개발자가 갖춰야 할 역량 중 하나 입니다. 알고리즘을 어떻게 구현할 것인가를 팀원들과 소통하면서 자연스럽게 생각을 정리하고 전달하는 연습도 할 수 있습니다.
컴퓨터에 앉아 코딩하기 전 펜과 종이를 들고 눈과 머리와 손을 굴려 보시는 것은 어떠신지요??
Software engineer가 되기 위한 여정Aree Oh2020년 서울시에서 주최한 강소기업탐방 프로그램에서 발표한 자료 입니다.
학교를 졸업하고 software engineer로 취직을 하기까지의 여정을 다뤘습니다
1. 개발자가 나에게 맞을지 고민하기 위한 방법
2. 개발자로 취직하기 (이력서/면접 준비 팁)
3. 개발자로 취직한 후 우리가 하는 일
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)Kay KimNoel Llopis가 Montreal International Game Summit 2006에서 발표한 내용을 번역.
Agile 중에서 XP에 대해서 주로 다룸.
자세한 것은 http://betterways.tistory.com/51 참조.
Source: http://www.gamesfromwithin.com/articles/0611/000112.html
애자일의 모든것KH Park (박경훈)- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
손코딩뇌컴파일눈디버깅을 소개합니다.Kwangsung Ha"손코딩뇌컴파일눈디버깅" 모임을 소개합니다.
백문이 불여일런, 트라이얼앤에러(Trial and Error) 식의 몹쓸 교육을 받아 온 개발자들이 코딩하기 전에 신중하고 꼼꼼하게 생각해보기란 쉽지 않습니다.
개발 시간 중 디버깅 시간이 절반 이상을 차지하고 있는 실정에 버그를 줄이기 위해 TDD니 유닛테스트니 많은 방법들이 개발되고 있지만 가장 일차적으로 중요한 것은 개발자들이 꼼꼼히 따져보는 것이 아니겠는지요?
미국의 선진 SW회사들은 이미 화이트보드에 PS문제를 푸는 것을 인터뷰 방식으로 채택하고 있습니다. 이는 이와 같은 풀이 방식이 개발자들의 기본 역량을 측정하기에 알맞은 지표라는 것이고, 개발자들이 기본적으로 갖춰야 할 역량이기도 하다는 것 입니다.
또한 자신의 생각을 명확하게 정리하고 다른 사람이 이해할 수 있도록 전달하는 Communication Skill 도 개발자가 갖춰야 할 역량 중 하나 입니다. 알고리즘을 어떻게 구현할 것인가를 팀원들과 소통하면서 자연스럽게 생각을 정리하고 전달하는 연습도 할 수 있습니다.
컴퓨터에 앉아 코딩하기 전 펜과 종이를 들고 눈과 머리와 손을 굴려 보시는 것은 어떠신지요??
14. Pair Programming 진행 방법
❏ 온라인 / 오프라인
❏ Navigator - Driver 방법
❏ 5분 단위 교대, 10분 단위 교대
❏ 온라인 : 허들, code with me, 원격제어
❏ 회고 : 좋았던 점 / 아쉬운 점
15. Pair coding Tools
1. 화면 공유 툴
a. 공유를 하는 쪽에서만 작업이 가능하다
2. 온라인 협업 도구
a. Coding 작업에 최적화 되어 있음
3. 원격제어 툴
a. 속도가 빠름
b. 전체 화면을 공유받기 때문에
상대방에게 의도를 비교적 쉽게 이해
16. 화면 공유 툴
❏ 허들(Slack), Google Meet
❏ 여러 사람이 동시에 화면공유가 가능
❏ 간단한 화면 주석 달기 기능
❏ Zoom
❏ 한 번에 한 사람만 화면공유가 가능함
❏ 화면 주석 달기 기능 우수
17. 온라인 협업 툴
❏ code with me
❏ pair coding mode에서는 스크롤에 문제가 있음
❏ 게스트 쪽에서 자동완성 및 다이얼로그가 안 보임
❏ Duckly
❏ Build 오류 내용이 안 보임
❏ IDE color가 안 나옴
❏ 처음 설정이 힘들었음
18. 온라인 협업 툴
❏ 게스트쪽 문제점
❏ 디자인 화면 볼 수 없었음
❏ build 사용이 불가능
❏ 팝업 메뉴가 안보인다
19. 원격제어 툴
❏ Zoom 원격 제어
❏ 대소문자 변환에 문제가 있었음
❏ Chrome 원격 데스크톱
❏ 쉽고 간단한 설정, 브라우저에서 사용
❏ 딜레이가 있음
❏ 뒤로 가기 버튼이 눌리면 종료됨
30. 1회차 4회차 7회차 11회차 회고
진행 단계
진행 방법 공유
pair coding
학습 병행
우리에게 맞는
방법을 찾는 실험
정형화된 방법을
찾아서 실행
전체 회고
31. History
❏ 1회차 : Pair Programming 계획 공유
❏ Tools, 진행 방법
❏ 2회차 : 체험학습?
❏ 5분 단위에 역할 교대
❏ pair coding 툴을 사용했고, 익숙해지는 시간이 필요했음
❏ Driver로 있을 때보다, Navigator 역할을 할 때 뭘 할지 익숙지 않음
32. History
❏ 3회차 : Offline Pair Programming
❏ 양방향, 빠른 피드백
❏ Online보다 많은 작업, 의사 표현
❏ 4회차 : 서로 잘 모르는 작업
❏ 원격제어 생각보다 좋았음
❏ Merge까지 작업이 쉽지 않음
33. History
❏ 5회차 : 서로 잘 아는 작업
❏ 10분 단위에 역할 교대
❏ 2시간 정도 까지 괜찮은 것 같음
❏ 6회차 : 단순하고 지루한 작업
❏ 생각보다 덜 지루함
❏ 한번 정도는 해보는것이 좋음
34. History
❏ 7회차 : 한쪽에 불편함을 주는 시도
❏ Driver가 아무 말도 안 하는 경우
❏ Navigator가 아무 말도 안 하는 경우
❏ 8회차 : 한쪽만 잘 아는 작업
❏ 각자 하나씩 준비
❏ 사전에 코드 리뷰 시간 후에 진행
35. History
❏ 9회차 : 코드 사전 리뷰
❏ 서로 아주 잘 알고 있는 코드로 만들기 위해
별도 코드 리뷰 시간을 가짐
❏ 10회차 : 리팩토링
❏ 소스 파일에 readme.md 파일을 만들어 정리
❏ 모듈 분리, API 결과를 Flow로 전환, Compose 적용
36. History
❏ 11회차 : 신규 작업, 아키텍처 작업
❏ 사전에 코드 리뷰 시간 후에 진행
❏ 12회차 : 회고
❏ 전체 회고 및 총평
37. 1회차 4회차 7회차 11회차 회고
진행 단계
진행 방법 공유
pair coding
학습 병행
우리에게 맞는
방법을 찾는 실험
정형화된 방법을
찾아서 실행
전체 회고
38. History
❏ 7회차 : 한쪽에 불편함을 주는 시도
❏ Driver가 아무 말도 안 하는 경우
❏ Navigator가 아무 말도 안 하는 경우
❏ 각 1번씩 교대로 진행
39. Driver가 수동적인 경우
❏ navigator
❏ 어떤 의도로 coding하는지 알
수 없어 답답함
❏ 오더를 잘 이해하고 coding하는
건지 모름
❏ driver
❏ 오더에 의한 coding
40. Navigator가 수동적인 경우
❏ driver
❏ 혼자 coding하는 듯한 느낌
❏ 익숙한 코드가 아닌 경우는 뭘
해야 할지 몰랐음
❏ 혼자 말하는 느낌이 들어 좀 더
말을 덜 하게 됨
❏ navigator
❏ coding 영상을 보는 느낌
❏ 집중력이 떨어짐
43. 효율적인 작업 방법인가?
❏ 혼자 할 때보다 시간이 줄어 들었나?
❏ 30% 정도 줄었음
❏ 통합에 걸리는 시간은?
❏ Review 시간이 대폭 감소 됨
❏ 버그 발생은 얼마나 줄까?
❏ 30% 줄어듦
44. 효율적인 작업 방법인가?
❏ 눈에 보이는 효과
❏ 시간비용이 큰 작업에 경우
❏ hotfix 대응
❏ 장애 대응
45. 효율적인 작업 방법인가?
❏ 당장 보이지 않는 효과
❏ pair coding으로 성장한다.
❏ 코드 스타일이 비슷해진다.
46. 시간효율
❏ 시간적 측면에서 본 pair coding
❏ 장기적 관점에서 확실히 이득 단기적 관점에서는?
❏ 같은 서비스를 오래 할수록 효과가 커진다.
47. 시간효율
❏ 효율을 높이기 위한 방법
❏ pair coding의 목표를 정하고 시작
❏ merge 가능할 때까지가 가장 효과가 좋았음
❏ Coding > Pull Requests > Approve > Merge
48. Pair Programming에 적합한 일은 뭘까요?
1. 일정 시간 이상에 리뷰가 필요한 작업
2. 도전적인 과제
a. 리팩토링, 구조개선
3. 신규 작업
4. 2명이상 투입 과제
5. 겹치는 부분이 많은 과제
49. 좀 더 어려운 경우가 있었나요?
❏ 단축키 커스텀을 많이 해 놓은 다른 사람 장비에서 할 때 힘들다
50. 적절한 시간은?
❏ 10분 단위 교대 괜찮았음
❏ Build 할 때 5분이 넘어가는 경우도 있어서
교대 간격이 좀더 길었으면 좋겠음
❏ 5분 단위로 교대 하는 것 자체는 괜찮았음
❏ 오랜 시간 같이 하는 것에 대한 의견
❏ 1:30 coding, 30회고, 2시간 정도는 괜찮음
51. Pair Programming 전제
1. pair programming 시간이 늘어나는 일이다.
2. 시간을 단축하는 것을 목표로 하면 안 된다.
3. 단기적인 효과를 기대하고 할 수는 없다
4. 장기적으로 팀원에 역량을 높이기 위해서 진행하는 것이 올바르다
53. 주니어 입장
1. 시니어의 추론 과정을 지켜볼 수 있음.
2. 코드 스타일을 통일 할 수 있음.
3. 다양한 도구 노하우 습득.
4. 코드 리뷰에 적응할 수 있음.
5. 자신감이 오름.
54. 주니어 입장
1. 시니어의 추론 과정을 지켜볼 수 있음.
2. 코드 스타일을 통일 할 수 있음.
3. 다양한 도구 노하우 습득.
4. 코드 리뷰에 적응할 수 있음.
5. 자신감이 오름.
55. 팁
1. 폰트 크기 조절
a. Ctrl + Shift + , 폰트 줄이기
b. Ctrl + Shift + . 폰트 키우기
2. 플러그인에서 IDE 기본 탑재
a. Presentation Assistant
b. https://www.jetbrains.com/help/idea/presentation-assistant.html
58. 주니어의 입장
1. 시니어의 추론 과정을 지켜볼 수 있음.
2. 코드 스타일을 통일 할 수 있음.
3. 다양한 도구 노하우 습득.
4. 코드 리뷰에 적응할 수 있음.
5. 자신감이 오름.
66. 서로 잘 모르는 코드
1. 학습 및 시간 소요가 줄어드는지 잘 모르겠음.
2. Merge까지 가하기 쉽지 않음.
a. Merge까지 할 때 시간 효율이 좋아지는데
b. Merge까지 못 가면 효율이 떨어짐.
67. 둘다 잘 아는 작업
1. 피드백에 빨랐음.
2. 헤매는 시간이 없었음.
3. 좀 더 많은 양을 한껏 같은 느낌이 듦
4. 실패 시에 다른 대안을 시작하는 게 빨랐음.
5. 알긴 하는데 한 번도 안 써본 것을 상대방이 잘 써서 관련 부분 학습효과가 높음
a. 모르는 부분 hilt binds 학습이 용이했음
추가적인 질의도 할 수 있었음
b. EntryPoint 관련 학습
68. 단순작업에 효과가 있나?
1. 생각보다 덜 지루함. 하기 싫은 일임에도 조금도 할만함.
2. 알 수 없는 오류를 빨리 찾음.
3. 혼자 할 때보다는 집중이 잘됨
4. 진행 속도는 혼자 하는 것보다 같거나 빠름
5. 처음 하는 작업이면 익숙해지는 데 도움이 됐지만 2번째는 별로임