Teo's Sprint DAY 4

오늘부터 드디어 개발에 들어가나 했는데, 아직도 회의할 것들이 너무 많이 있었다는 게 함정..!
정해도 정해도 정해야 할 것들이 끝없이 늘어난다 꾸엑...  무엇을 정하고 무엇을 더 정해야 하는지 알아보즈아

---

BDD 첫 경험

BDD ( behavior-driven development, 동작 기반 개발 또는 행동 중심 개발)
BDD는 소프트웨어 프로젝트에서 개발자, 품질 보증 전문가 및 고객 대표 간의 협업을 장려하는 민첩한 소프트웨어 개발 프로세스입니다. 
팀이 대화와 구체적인 예를 사용하여 응용 프로그램의 작동 방식에 대한 이해를 공유하도록 권장하며,
테스트 주도 개발 (TDD)에서 등장했습니다.

BDD는 다음에 중점을 둡니다.
- 프로세스의 시작 위치
- 테스트해야 할 것과 테스트하지 말아야 할 것
- 한 번에 테스트할 양 테스트를 부르는 것
- 테스트가 실패하는 이유를 이해하는 방법

[ 출처 : https://en.wikipedia.org/wiki/Behavior-driven_development ]

 

즉, BDD는 사용자의 행동을 중심으로 개발을 진행하는 방식으로,
화면을 보고 사용자는 행동을 하며, 행동은 데이터의 변화를 야기하고,
데이터의 변화는 다시 화면으로 그려지는 계속되는 사이클의 반복이 곧 프런트엔드 프로그래밍이다.
- 테오의 스프린트 -

 

스케치를 통해서 화면을 중심으로 사고를 해봤다면 이번에는 사용자의 행동을 중심으로 정리해보는 시간인 거다!

"사용자가 글을 작성하려 한다"라고 가정해보자.
WHEN (사용자 행동) : 글 작성 버튼 누르기
THEN (행동의 결과)  : 작성 페이지로 넘어간다.
                                    작성 페이지로 넘어가지 않고, 로그인 페이지로 넘어간다.
GIVEN (행동의 결과가 다를 때의 조건) :  로그인을 했을 경우 -> 작성 페이지로 넘어간다.
                                                           로그인을 하지 않았을 경우 -> 로그인 페이지로 넘어가서, 로그인 유도

위와 같이, 각 페이지마다 사용자가 행동할 수 있는 모든 경우의 수를 다 적는 것이다.
이렇게 작성하면, 나와 팀원들이 생각했던 모든 사용자의 예상 행동이 가시화되어있어서 개발하기 몹시 수월하며,
지금같이 협업인 경우에는 특히 task 분배하기에도 너무 수월했었다.

예전에 어떤 영상에서 개발자들이 새로운 프로젝트에 들어가면, 회의실에서 회의만 며칠, 몇 주동안 내내 한다는 것을 들은 적이 있다. 정말이었어... 이 정도 규모의 프로젝트도 회의를 해도 해도 계속 새로운 얘깃거리가 나오는데, 큰 규모의 서비스는 어떨지 감이 안 온다. (근데 우리는 첫 팀플이고 회사는 이런 부분들에 대해 어느 정도 문서화가 되어 있긴 하겠지..?)
개발 회의에 대해 1도 몰랐던 것 같다는 생각이 드는 요즘이다~ 아직도 배울 것들이 다방면으로 너무너무 많다!!!

---

아직은 조금 이른 SDD 랄까나..?

SDD(Schme Driven Development)는 데이터를 중심으로 추려내고 개발을 진행하는 방식으로,
개발을 하기 전에 미리 공통적인 스키마(데이터 구조)를 정하고 그에 맞춰서 개발을 하자라는 방법론이다.

일반적으로 백엔드와 프런트엔드 개발자가 함께 사용해야 할 API를 만들어야 할 때 백엔드가 모든 기능을 다 구현을 끝낼 때까지 기다리기 전에 서로 인터페이스만 맞춰두고 각자가 개발을 하는 형태와 유사하다.

복잡한 구조의 프로젝트를 만들어야 할 때에는 구현을 하면서 부딪혀가며 진행하지 않고,
미리 아키텍처 등을 설계하거나 데이터베이스를 미리 설계해보는 것도 이러한 방법에 속한다.
개발에서는 굉장히 일반적인 방법.

 출처 : https://velog.io/@teo/behavior-driven-development-schema-driven-development

 

분명 해당 부분도 해보면 당연히 매우 좋겠다는 생각이 들었지만,
스키마(데이터 구조)를 정한다면 자연스럽게 TS를 사용하게 되는, 해당 프로젝트에서 카카오 API의 비중이 매우 큰데,
TS까지는 지원이 되지 않아서 5-6일의 단기 프로젝트에는 TS까지는 적용하는 것이 힘들겠다는 판단 하에 SDD도 과감히 스킵하였다.

하지만, 이렇게 개발 들어가기 전에 데이터 구조를 미리 정한다면 개발을 하는 것이 더욱더 쉽고,
따로 이것저것 물어볼 필요 없이, 스키마를 통해 내가 어떻게 진행해야 하는지 명확히 알 수 있을 것이라고 생각된다.
해당 플젝이 끝내고 개인 프로젝트를 시작할 때, TS를 적용해보면서 SDD까지 정하면 찐 개발자로 한 걸음 더 다가가겠지!?

---

회고를 하며...

문서화, 소통, 공유, 이해와 존중... 모든 것이 매우 중요하다.
분명 회의에서 말한 것인데, 문서화하지 않으면 또 잊어버리고 남들에게 질문해서 나는 민망하고, 그분은 귀찮고ㅠ
나의 상황을 공유하지 않으면, 다른 사람들은 당연히 내 상황을 모르지! 알면 그것 또한 소름!
무엇을 하든 소통!! 모든 부분을 당연하게 생각하지 말고, 디테일하게 소통할 수 있도록 발전시키자!
또한 다른 분들의 상황을 이해하고 나 또한 언젠가 그 상황이 올 수 있다는 것을 명심하자!
인생 절대 혼자 사는 거 아니다! 모두와 같이 둥글게 둥글게 살아보자!

---