이 글은 우아한테크코스 1 주차의 인사이트와 느낀점을 기록한 글입니다. 🗓 02/07(화) ~ 02/11(금)

구현한 코드에 대해 E2E 테스트를 작성해보고, 읽기 좋은 코드로 리팩토링한다. 페어프로그래밍을 경험해보는 것을 통해 협업 능력을 키워본다.

페어 프로그래밍

이 절은 기존의 경험을 서술하였기에 글이 너무 깁니다. 내가 뭘 느꼈는지만 보고싶으면 이번의 경험 ✅ 만 보도록 하세요

우아한 테크코스가 지향하는 페어 프로그래밍은 다음과 같다.

애자일 소프트웨어 개발 중 하나로 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법이다. 코드를 작성하는 사람이 진행자(dirver)가 되고 다른 한 사람이 관찰자(observer, navigator)가 되어 코드 검토를 하며 프로그래밍을 작성한다. 두 프로그래머는 수시로 역할을 바꾼다.

간단히 말해 두 명의 작업자가 하나의 디바이스로 작업을 하고 이 때 한 명은 직접 코딩을, 다른 한 명은 지시자가 되어 조언하며 프로그래밍을 해나가는 방식을 페어 프로그래밍이라 하는 것 같다. (이렇게 이해함❗️)

이전의 경험 ❌

페어 프로그래밍 방식, 이전 팀에선 짝 코딩이라 부르며 이를 직접 해본 적이 있다. 그 때는 둘이서 하나의 디바이스로 코딩하는 것 그 자체를 짝 코딩이라 생각하며 좋다 좋다 하며 작업하였지만 지금 생각해보니 두 가지 잘못된 점이 있었다.

1. 수시로 역할을 바꾸지 않았다.

2. 상하관계가 존재하였다.

이전 오즈의 제작소에선 프론트 개발자 중 직접 서비스를 개발해본 경험을 가지고 있던 사람이 오직 나뿐이었다. 같은 팀원들은 이제 막 개발을 시작해본 내 후배들이었고, 효율성을 위해 짝 코딩을 진행하였다.(사실 그냥 후배들이 못해올 것 같고, 귀찮았던 것 같다)

그러다 보니 본인이 driver 이자, navigator가 되었었고, 팀원들은 그저 지켜만 보는 사람들이 되었다. 또, 본인에게 유 경험자라는 권위가 생겨 같은 팀원들이 좋은 아이디어를 낼 수 있음에도 못 내게 했던 것 같다.

결국 내 생각대로만 코드가 나오게 되었고, 이는 결코 협업이라 할 수 없었으며 같은 팀원들의 성장, 프로덕트의 완성도에 결함을 주게 되었다고 생각한다.

이번의 경험 ✅

우아한 테크코스가 제안하는 대로 1. 수시로 역할을 바꾸고자 하였고, 2. 상하관계를 만들지 않기 위해 대화법을 신경쓰며 짝 코딩을 진행해보았다.

상하관계가 없어서 인지 서로 의견을 부담없이 던질 수 있었고, 좋은 아이디어는 좋은 아이디어 대로 수용, 그 반대의 아이디어는 서로 왜 불필요한지 토론해보며 의미 있는 협업을 할 수 있었다.

또 수시로 역할을 바꾸면서 진행하였기에 게임을 하는 듯한 재미도 있었고, 누군가에게 배운다라는 느낌이 들지 않아 편하게 했던 것 같다.

서로 좋은 아이디어에 칭찬하고 박수치다 보니 자존감도 올라가는 것만 같고, 하나의 개발자로서 더 자신감을 갖게되는 것 같기도 했다.

(물론 이번 페어 프로그래밍을 같이하게 된 크루 덕분이다. 그 분은 협업 대마왕이다)

느낀점 🙏

1. 가장 중요한 것은 상하관계가 없어야 한다는 것. 내가 아는 것을 가르칠려 들지말고 제안하듯 대화해야한다고 생각했다.

2. 수시로 역할을 바꾸며, 서로의 코드 스타일을 익힌다. 내 코드 방식을 강요하지 말고 제안해보자

Software TESTING

why need

1. 내가 구현한 기능을 자동 테스트로 검증
2. 내가 짠 코드가 실제 기능이 잘 동작하는지 검증
3. 사용자의 입장에서의 사이클을 순서대로 기록
4. 기존 기능과 연결된 새로운 기능을 개발한 후 기존 기능이 잘 동작하는지 빠르게 확인하고 싶다면?

이전의 경험 ❌

테스팅을 귀찮은 과정정도로만 생각했던 오즈 시절엔 새로운 UI를 추가할 때, 기존의 UI와 연관되어 있다면 기존 기능의 검증에 수동 테스트(유저의 사이클을 하나 하나 직접 돌아보며, console.log로 찍어보는 테스트를 진행하였다.)를 진행하였다.

• 테스트에 들어가는 시간 비용이 크다.

• 단순 노가다이기에 정신적으로 피폐해짐.

• 기존 기능의 검증에 필요한 조건들을 기록해두고 테스트하는 것이 아니기에 제대로 된 검증이 되지 않을 수 있다.

이번의 경험 ✅

우선 TDD를 하고자 하였다.

문제를 정의하고 이를 해결해나가는 과정.

페어와 함께 진행한 방식은 다음과 같다.

1. 기능 요구사항을 분석하고, 테스트 해야하는 부분들을 기록한다.

2. 테스트 해야하는 부분에 대한 테스트 코드를 작성한다.

3. 어플리케이션의 개발 이전이기에 이 테스트 코드는 무조건 실패

4. 이 테스트 코드가 성공이 되는 것을 목표로 개발을 진행한다

느낀점 🙏

내부 구현을 변경하거나, 리팩토링 과정을 거쳤을 때 테스트 해보는 시간이 확연히 빨라졌고, 어떤 부분에서 에러가 발생하는지 빠르게 확인할 수 있었다.

• 프로덕트 검증 시간 빨라짐

• 디버깅에 걸리는 시간 빨라짐

• 유저가 사용하는 사이클을 기록해두었기에 헷갈리지 않음

Ref

• cypress docs

• cypress cheat-sheets