[맛팁 2] 프로덕트 스케치, BDD & SDD (w/ 도메인 구매)

프로젝트를 시작한다고 포스팅해 놓고 벌써 일주일이 지났지만 개인적인 중요한 일정들이 많이 생겨서..
부끄럽게도 많은 진전이 없었다..ㅠ (사실 이번주도 여러 일정들이 있음 ㅠ)
프로젝트를 시작하면 "현재 공부 중인 영어, 알고리즘, CS 공부를 포기하고 프로젝트만을 진행" vs "시간표를 짜서 시간표대로 병렬적으로 공부" 사이에서 늘 고민이 되는 것 같다.
알고리즘도 영어공부도 매일 하는 것이 좋고, 그래야 실력이 향상된다 생각하기에 영어, 알고리즘과 CS공부의 양을 어느 정도 정해놓고 이후의 시간을 프로젝트에 쏟는 방향으로 결정했다.

---

이번 프로젝트에서 이룬 것

• 프로덕트 스케치
• BDD
• SDD
• 도메인 구매
• 프로젝트 플랜

---

프로덕트 스케치

지난번의 워드 클라우드 구체화, 스토리 보드 및 레퍼런스 등을 참고로 해서 스타일링해야 할 스케치와 대략적인 기능들을 피그잼에 작성했다.
원래 피그마로 내가 직접 디자인을 해볼까 라는 생각도 했었는데...
피그마로 간단한 작업만 해봐서 배우려면 또 오랜 시간이 필요한데, 나는 디자이너가 아니라서 지금 피그마를 배우는 것은 중요하지 않고 시간 낭비일 것 같다는 판단 하에 핀터레스트에서 가져온 레퍼런스에서 내가 원하는 디자인부분만 편집해서 짜깁기하였다.

따라서 내일부터는 이 스케치대로 스타일링할 예정이다.

---

BDD

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

https://en.wikipedia.org/wiki/Behavior-driven_development

 

BDD를 찾아보던 중 테오의 스프린트에서 Given, When, Then의 구조에서 외에도 Feature, Scenario의 절을 추가해서 하나의 패턴으로 불린다는 것을 알게 되었다.

BDD는 시나리오를 기반으로 테스트 케이스를 작성하며 함수 단위 테스트를 권장하지 않는다.
이 시나리오는 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 레벨을 권장한다.
하나의 시나리오는 Given, When, Then 구조를 가지는 것을 기본 패턴으로 권장하며 각 절의 의미는 다음과 같다.

Feature : 테스트에 대상의 기능/책임을 명시한다.
Scenario : 테스트 목적에 대한 상황을 설명한다.
Given : 시나리오 진행에 필요한 값을 설정한다.
When : 시나리오를 진행하는데 필요한 조건을 명시한다.
Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다.

위의 내용을 개발 측면에서 더 간략하게 정리하면 테스트 대상의 상태 변화를 테스트하는 것이다.

테스트 대상은 A 상태에서 출발하며(Given) 어떤 상태 변화를 가했을 때(When)
기대하는 상태로 완료되어야 한다.(Then)
또는 Side Effect가 전혀 없는 테스트 대상이라면 테스트 대상의 환경을 A 상태에 두고(Given)
어떤 행동을 요구했을 때(When) 기대하는 결과를 돌려받아야 한다. (Then)

https://www.popit.kr/bdd-behaviour-driven-development%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B0%84%EB%9E%B5%ED%95%9C-%EC%A0%95%EB%A6%AC/

---

혼자 하는 프로젝트이고, 내가 어떤 시나리오대로 진행할지 다 알기 때문에 Feature와 Scenario는 생략하였다.
더 많은 페이지들이 있지만 스프린트 방식대로 하기 위해 MVP만 먼저 작성하고, 나머지는 또 나중에 다시 진행할 예정.

로그인페이지로 예를 들어보면 나는 소셜 로그인을 구현해 본 적이 없기에 이번 기회에 카카오톡과 지메일 로그인을 진행해 볼 예정이다. 내가 구현하려는 프로젝트는 로그인을 하지 않아도 어느 정도 사용이 가능하기에 첫 화면부터 로그인을 강요하지 않고, 로그인이 필요한 기능을 누를 경우에만 로그인 페이지를 띄울 예정이다.

Given : 또한, 로그인을 하지 않은 사람에게만 로그인 버튼을 클릭하면 해당 페이지가 나오므로 Given은 작성할 것이 없음.
첫 화면부터 나온다면 Given을 통해 로그인을 한 사람과 하지 않은 사람을 나눠야 할 것이다.

When : 로그인 페이지에서 사용자가 경험할 수 있는 시나리오는 세 가지이다. 카카오톡, 지메일 로그인 또는 뒤로 가기.

Then : 카카오톡 또는 지메일에 로그인한 후, 무조건 메인 페이지로 이동하거나 해당 페이지에 남아 있기보단
사용자가 있던 이전 페이지로 이동하는 것이 사용자 경험 상 좋을 것이기에, 이전 페이지로 이동하는 것으로 설계할 것이며
뒤로 가기 버튼은 당연히 이전 페이지로 이동해야 한다.

---

SDD

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

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

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

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

그래서 SDD를 기반으로 화면에서 해야 할 일은,
1) 화면 단위에서 변화하는 모든 것들을 찾아낸다.
2) 그리고 그것들에게 모두 이름을 붙여준다.
3) 구조가 같은 것끼리 그룹을 지어준다.
4) 화면을 위한 것과 비즈니스를 위한 데이터를 구분한다.

BDD의 then은 결국 자연어로 기술되어 있지만 최종적으로 데이터의 변화를 의미하는 것입니다.
따라서 BDD의 then이 SDD에 언급된 데이터의 변화로 나타낼 수 없다면 잘못되었거나
모호하게 기술이 되었거나 스키마에 새로운 데이터가 필요하다는 신호입니다.

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

---

테오의 블로그에 따르면 SDD를 통해 BDD를 검증할 수 있어야 하고, 반대로 BDD를 통해서도 SDD를 검증할 수 있어야 한다고 했다.

• 로그인 버튼을 클릭하면 로그인을 하지 않았을 경우에만 로그인 함수가 작동된다.
  (이건 사실 jsx안에서 삼항으로 작성하는 것이 더 가독성 좋을 것 같음)
• 로그인 함수를 생성하여 카카오 로그인 버튼을 클릭하면 카카오 로그인, 지메일 로그인 버튼을 클릭하면 지메일 로그인이 실행된다.
  • 로그인 성공 후에 이전 페이지로 이동하는 함수가 실행되어 이전 페이지로 이동한다.
    로그인 후의 사용자_정보를 담아서 같이 이동한다.
• 뒤로 가기 버튼을 클릭하면 이전 페이지 함수가 작동하여, 이전 페이지로 이동한다.

테오 스프린트 때는 TS가 아닌 JS로 진행하였기에 SDD를 하지 않았기에 어떤 식으로 진행하는지 설명은 들었지만, 제대로 와닿지는 않았었어서 궁금했었다.
이번에는 개인플젝이기에 TS도 진행하고 SDD도 설계하면서 내가 하고 싶은 대로 다 하는 중이다! 흐흐
TS는 간단한 토이 팀프로젝트에서 짧게 짧게  적용해 본 적은 있지만, 개인 프로젝트에서 적용하는 것이 처음인데 SDD까지 설계하려니 생각보다 오래 걸렸다.
맞게 한건진 모르겠지만 프로젝트에서 기능 구현하는 것처럼 생각해 보며 리허설?을 하는 느낌이었다.
설계만 제대로 해놓으면 기능 구현할 때 훠얼~씬 수월하다는데 어떨지 궁금하다!! 빨리 기능구현 해봐야겠다!!
다음 Backlog때는 더 수월하게 할 수 있지 않을까? 이런 것도 점점 하다 보면 늘겠지!

---

도메인 구매

지난번에는 프로젝트 이름을 이재해(이 재료로 요리해!)로 생각했었는데 스케치하고 설계하면서 생각이 바뀌었다.
맛팁!으로 바뀌었다ㅎ.ㅎ 맛있는 요리팁! 맛의 팁! 이런 느낌이랄까..?
후보가 몇 개 있었는데 ChatGPT한테 물어봤더니 맛의 팁이 제안하길래 맛팁으로 결정해 버렸다!

하는 김에 제대로 해보자 하고, 도메인도 구매하였다.

.com, .co.kr 같은 건 세일 안 하고 너무 비싸길래 저렴하게 .site를 구매하였다 흐흐흐
아직 뭐 한 것도 없는데 도메인 구매하니까 기분이 조크든요~

---

프로젝트 일정

오늘을 시작으로, 매주마다 일정을 계획하고 실천하려고 한다.
이렇게 계획하고 보니... 다른 공부도 병행하고 있어서 더더욱 스프린트처럼 5-7일 만에 끝낼 수가 없겠네^^
나만 하루가 60시간이었으면 좋겠다~~~

사실 매번 무엇을 계획할 때마다 욕심을 부리지만 변수가 생기기에 백 퍼센트 완벽히 실천하기는 어려운 것 같다.
그럼에도 불구하고 계획 없이 진행하는 것보단 계획을 하고 체계적으로 진행해야만 내가 놓치고 있는 부분, 그렇기에 아쉬운 부분, 수정해야 할 부분과 진행 상황 등을 체크할 수 있다.

타이트하게 세운 계획이기에 너무 압박받지 말고, "열심히 하고 있으니 후회 없어!"라는 생각이 들게끔 3월도 열심히 달려보자!

---