저번에 이은 다른 기능을 소개하려고 한다.

바로 zip, tar 확장자를 가진 파일을 받아 업로드 시키고, 그것을 리스트로 만들어서 텍스트 파일 형태라면 편집까지 가능한 구조이다.

Frontend부분을 먼저 보면서 flow대로 설명을 하도록 하겠다.

🚀 FrontEnd - 페이지만들기

State 설명

• uploadFile: 업로드 할 파일을 선택했을 때 저장된다.
• fileList: 업로드가 완료되면 해당 압축 파일을 풀어 리스트 형태로 파일 리스트를 저장하게 된다.
• selectFile: 편집할 파일을 선택했을때 해당 파일의 경로가 저장되게 되는데 특이한건 해당 index로 저장되어 fileList를 통해 찾을 수 있다.
• contents: 편집할 파일의 내용이 담기게 된다.

upload

업로드 파일을 선택하는 <input>을 만들고 onChange가 일어나게 되면 uploadFile을 업데이트 해준다.

업로드 버튼을 눌렀을때 uploadFile이 비어있다면 에러핸들링을 통해 에러를 일으키고 정상적으로 업로드가 된다면 압축을 푸는 과정을 거친다. 여기서는 백엔드에서 압축을 풀어 파일을 저장시키는 시스템과 프론트엔드에서 압축을 풀어 해당 리스트를 얻어보는 방법을 채택하였다.

31번째 줄부터 시작하는 코드가 해당 코드이며, JSZIP 라이브러리를 이용하여 경로와 dir(해당 파일이 폴더인지 아닌지) 값을 얻을 수 있다. 얻은 값은 FileList에 저장된다.

file edit

fileList를 얻었다면 해당 내용은 render()의 부분(106번째 줄) <li>태그를 만들어서 나타내준다.

해당 태그를 클릭했을때 폴더라면 에러처리를 반환하고, 아니라면 해당 내용을 axios를 통해 불러와 <textarea>로 불러와 편집이 가능하게 한다.

🚀 BackEnd

해당 파일들은 따로 DB에 저장하지 않고 사용이 된다. 그래서 upload를 처리하는 js만 만들어 구현했다.

upload.js

multer를 사용해서 파일 업로드를 해주었다. 해당 경로는 src/files/에 저장을 해두었고, 파일의 이름 또한 <해당 유저 id>_<원래 이름>으로 설정하여 저장했다.

API

API는 총 3개로 나뉜다.

1. 업로드 될 때 실행되는 POST
2. 파일의 내용을 얻어오는 GET
3. 파일의 내용을 변경한는 POST

업로드 될 때 실행되는 POST

우리가 만들어둔 upload.js를 require을 해와서 사용한다. 압축 파일 자체를 저장시켜 준 뒤, 압축을 푸는 amd-zip을 이용하여 압축도 풀어준다.

해당 api가 잘 작동 되면 front에서는 파일 압축을 풀어 fileList에 저장하는 과정이랑 연결된다.

파일의 내용을 얻어오는 GET

절대 경로로 찾아올 파일의 경로를 설정해준뒤 fs의 속성을 이용하여 가져와서 contents를 반환하게 된다.

파일의 내용을 변경한는 POST

GET과 마찬가지로 fs를 이용하여 변경해주는 간단한 API를 실행해준다.

이번 프로젝트에서는 2가지의 기능을 핵심으로 설정을 했다.

1. 실시간 채팅(+ 귓속말)
2. 압축된 파일 풀어 리스트 만들기(+ 편집)

우선은 실시간 채팅에 대해서 자세히 블로깅을 시작하겠다!

🚀 socket.io 설정하기

node의 express를 기본으로 사용을 하였다. app.js에서 등록을 하여 설정을 해주어야 하는데, 나는 이것을 따로 socket.js파일로 빼내어 정리를 한다음 app.js에서 다시 _require_해주었다.

socket.js 생성

module.exports를 통해 외부에서 require로 리턴 할 수 있게 해주었다. socket의 연결은 connection으로 연결을 해주었고, 연결이 됐을때(connection)와 연결이 해제되었을때(disconnect) 구분해줄 ip를 선언하고 이용하였다.

새로운 접속 ::ffff:172.17.0.1 zRomb4oZ26jTwQd5AAAB
클라이언트 접속 해제 ::ffff:172.17.0.1 zRomb4oZ26jTwQd5AAAB

나머지 기능은 채팅의 BackEnd에서 자세히 설명

app.js에 등록/연결

회색 부분은 나머지 설정이라 볼 필요는 없다.

const main을 보면 redis로 선언된 server를 우리가 설정한 socket.js에서 불러와 연결을 해주었다.

이럼으로 서버에서는 socket을 통해 이용할 수 있게 되었다.

🚀 DB 스키마 설정

mongodb는 noSQL이지만, 그래도 스키마 형태로 가공해주는 것이 편리하기 떄문에 스키마 설정을 해주었다. (mongoose 사용)

필요한 필드 정리

채팅에서 공통적으로 필요한 것들은 다음과 같다. 보낸 사람, 메세지 내용, 메세지 날짜(날짜는 db에서 필수적이다.) 그리고 귓속말 기능에서는 추가적으로 받는 사람이 필요하기에 이것을 구분해줄 타입(귓속말인지 아닌지)으로 나누어 구축을 해주었다.

chat.js 생성

필수적으로 필요한 것들은 require을 true로 설정했다. 그리고 createAt은 지금 등록된 날짜를, type은 기본적으로 전체 채팅을 뜻하는 public으로 설정하였다.

user는 이미 만들어둔 것으로 ref를 통해 참조 할 수 있도록 했다.

🚀 전체 채팅 구현

FrontEnd - 메인 페이지

socket으로 현재 socket을 사용할 주소를 입력하여 선언한다.

componenteDidMount()에는 mount됐을때 실행되어야 할 것들을 선언해준다.

• user_id 받아오기
• 전에 있던 채팅들을 받아오기 (logs)
• joinChat으로 socket의 유저리스트에 등록을 시킨다.
• getUserList를 통해 새로운 유저가 들어왔을때 userList를 업데이트 해준다.
• 새로운 전체 채팅 메세지를 받으면 logs를 업데이트 해준다.

보여지는 페이지는 총 3부분으로 나눌 수 있다.

1. 채팅이 보이는 채팅 보드

logs를 통해 지난 메세지들을 받아오면 map을 통해 MessageBox라는 Component를 돌려준다.

내가 보낸 것인지, 상대방이 보낸 것인지, 귓속말인지에 따라 CSS설정을 다르게 하여 잘 구분될 수 있게 하였다.

내가 보낸 메세지는 오른쪽 정렬로 아이디 없이 표시하였다.

다른 유저가 보낸 메세지들은 왼쪽 정렬을 했다.

청록색은 귓속말로 어떤 유저에게 보내는지 보여진다. 위에서는 codesign이 code에게 보내는 귓속말이다.

일반 채팅의 경우 하얀색 바탕으로 받게 된다.

2. 귓속말 상대를 선택할 수 있는 셀렉트

componentDidMount()가 실행이 되면서 userList를 받아오게 되는데 이것이 접속해 있는 유저들의 리스트이다. 이것을 통해 귓속말 할 상대를 정할 수 있게 된다.

마찬가지로 map을 통해 리스트를 만들었고, 해당 리스트의 유저를 클릭하면 해당 유저에게 메세지를 보낼 수 있게 된다. 동시에 state의 type, toUser가 바뀌게 된다. 물론, 자기 자신을 선택할 수는 없다.

3. 메시지를 입력하여 내보내는 인풋창

기본적으로 bootstrap으로 디자인을 하였고, onChange를 통해 state의 message를 바로 변경 가능하게 하였다.

버튼을 누르면 해당 메세지가 귓속말인지 아닌지, 비어있는지 아닌지 등을 확인하여 백엔드와 통신하게 되고 잘 통신이 되었다면 socket을 통해 전체 메세지를 전달하게 되고, 해당 state들을 초기화해준다.

BackEnd

다시 보자 socket.js !!

새로운 유저가 접속을 하게 되면 socket.join을 통해 등록을 시키고, userList에 추가하게 된다. 그리고 업데이트된 userList를 전체 socket으로 보내어 받게 된다.

채팅은 전체 채팅과 귓속말이 나누어져 있는데, 한 socket의 기능에서 처리하게 하였다. 전달받은 object의 toUser가 있다면 귓속말이므로 해당 소켓의 아이디를 가진 사람에게만 전달하기 위해 io.to(받을사람 id).emit()으로 처리하였다.

만약 접속을 해지하게 된다면 splice 내부 함수를 사용하여 해당 유저를 제외하게 했다.

API

[GET] /init API

처음 페이지에 들어와 실행하게 되는 /init에서는 모든 채팅을 찾게 된다. 해당 함수인 findAllChats는 접속한 유저의 아이디를 통해 DB를 다음과 같은 조건으로 조회하게 된다.

• 전체 채팅 -> toUser가 없는 채팅들 또는
• toUser가 접속한 유저인 것 (귓속말 받은 상대가 해당 유저) 또는
• user가 접속한 유저인 것 (귓속말 보낸 사람이 해당 유저)

이렇게 되면 다른 사람에게 보낸/받은 메세지들을 제외하고 조회하게 된다.

[POST] /message API

메세지를 보내는 기능들 담당하는 이 API는 addChat 함수를 실행한다. 해당 함수는 전체 채팅인지 귓속말인지를 판단 후 넘겨 받은 Object를 DB에 저장시킨다.

• Vuex란?

  • 무수히 많은 컴포넌트의 데이터를 관리하기 위한 상태 관리 패턴이자 라이브러리
  • React의 Flux 패턴에서 기인함
  • Vue.js 중고급 개발자로 성장하기 위한 필수 관문

• Flux ?

  • MVC 패턴의 복잡한 데이터 흐름 문제를 해결하는 개발 패턴
  1. action: 화면에서 발생하는 이벤트 또는 사용자의 입력
  2. dispatcher: 데이터를 변경하는 방법, 메서드
  3. model: 화면에 표시할 데이터
  4. view: 사용자에게 비춰지는 화면

• MVC 패턴과 Flux 패턴

  MVC 패턴의 문제점

  

  Flux 패턴의 단방향 데이터 흐름

  

• Vuex로 해결 할 수 있는 문제

  1. MVC 패턴에서 발생하는 구조적 오류
  2. 컴포넌트 간 데이터 전달 명시
  3. 여러 개의 컴포넌트에서 같은 데이터를 업데이트 할 때 동기화 문제

• Vuex 컨셉

  • State: 컴포넌트간에 공유하는 데이터 data()
  • View: 데이터를 표시하는 화면 template
  • Action: 사용자의 입력에 따라 데이터를 변경하는 methods

Brandi internship을 진행하다 보니 vue.js가 필요한 상황이었다. 그래서 열심히 책도 읽고 강의도 찾아보면서 todo list를 만들어 보였다.

어떤 기술들을 이용했는지?

• vue.js
  • component로 만들어 사용
  • props, event 이용 데이터를 올리고 내리고 하는 기능을 이용해봄!
  • route 이용
• vuex
  • store 디렉토리를 이용하여 중앙 데이터 관리
  • 헬퍼 함수를 이용
• storage에 저장하여 새로고침해도 사라지지 않음!

시연 영상

일단 vue.js를 공부하기 위해서는 js에 대한 공부가 필요했다.

다음은 내가 js를 공부하면서 몰랐던 내용들에 대해 정리한 내용이다.

• computed VS watch computed: 자주 사용하는 것들에 사용 watch: 자주 사용하지 않는 것들에 사용

• ES6 특징

  • Hoisting x
  • const, let 추가 (var 사용 x)
  • arrow function

      var a = function(b) {
          return b
      }
      let a = b => { return b}

  • 축약 function

      a = {
          b: function() {
              return 10
          }
      }
      a() { return 10 }

  • 같은 경우의 function 줄이기

      var a = {
          'b': b
      }
      let a = {
          b
      }

  • Modules
    • default export는 한 파일당 하나만 export한다는 뜻

새롭게 공부하는 과정이지만, 새로운 지식을 배우는것이 나는 참 즐겁다!

python의 너무 깔끔한면이 js를 공부하면서 장단점을 더 명확히 알 수 있는 소중한 시간을 보내고 있는 것 같다. js의 고수가 되어서 typescript도 정복하고 node.js도 배워보고 싶다!

이번에 Brnadi 인턴쉽과정을 하게 되었다! 다행이 Brandi는 프로젝트 준비와 인턴들의 관리가 굉장히 잘 되어있는 기업이었다!! (너무 만족스럽고 다행이었다.)

인턴은 총 5명으로 백엔드만 5명이었기 때문에 조금이나마 UI를 다뤄본 내가 '일단'은 Frontend를 맡게 되어 진행하게 되었다.

기술스택으론

• flask(백엔드)
  • ORM 사용 x
• Vue.js (프론트엔드)

였기 때문에 나는 급한데로 vue.js 공부를 하기 시작했다! 하지만 하루이틀만에 하기엔 무리가 되는 new framework... 내 마음은 하루하루 지날때마다 불안해지기 시작하면서 뭔가에 쫓기는 느낌이 들었다. (당장이라도 뭔가를 뽑아내야 할 것 같은 느낌이었다.)

다행히도 팀장님이 전 인턴들이 하던 UI를 제공해 주어서 그것을 바탕으로 진행하게 되었다. 하지만, 모든 페이지가 있지 않아 어떤 UI가 있고 없는지에 따른 파악을 먼저 하기로 하였다.

다음은 그 파악을 위한 문서이다! (이제부터 내가 구멍들을 메꾸어야 할 녀석들이다...☠️)

• UI 상황
  • 서비스
    • 유저
      • 로그인
      • 회원가입
      • 회원가입 - flow
    • 상품 리스트
      • 헤더 부분(필터)
      • 바디 부분(상품 이미지, 타이틀, 가격 등)
    • 상품 디테일
      • 헤더 부분(사진, 사이즈/색상 선택, 가격 등)
      • 바디 부분(상품 정보)
      • QnA 등록
      • QnA 리스트
    • 결재
      • 결재 상황 페이지(주소, 수량체크 등등)
      • 주소 선택 모달창
      • 주문 완료 페이지 ???-없는거같다
    • 장바구니
      • 장바구니에 대한 전체 부분
    • 마이페이지
      • 마이페이지 헤더(주문 배송조회, 포인트, 쿠폰 등등)
      • 주문 리스트
      • 주문 상세 페이지
      • QnA 리스트
    • 혜택존
      • 슬라이드
      • 상세이미지 (디테일)
      • 상세이미지 (상품리스트)
  • 어드민
    • 홈 (매출통계, 상품 상태 현황) - seller
    • 회원
      • 로그인
      • 회원가입
    • 회원관리
      • 샐러계정관리 - master
      • 샐러 정보 수정페이지 - master
      • 샐러정보 관리 - seller
    • 상품 관리
      • 상품 관리 - master
      • 상품 관리 - seller
      • 상품 등록 - master
      • 상품 등록 - seller
    • 주문 관리
      • 상품 준비 관리 - seller
      • 상품 준비 관리 - master
      • 배송중 관리 - seller
      • 배송중 관리 - master
      • 배송 완료 관리 - seller
      • 배송 완료 관리 - master
      • 구매 확정 관리 - seller
      • 구매 확정 관리 - master
      • 주문 상세 관리 - seller, master
    • 기획전
      • 기획전 등록 - master

이제부터 UI공장이 되어 나의 원래 신분이었던 백엔드로 돌아가는 날까지 화이팅이다!!!

아즈아!😆🙌

프로젝트를 진행하다보니 서로 다른 querySet을 합쳐야 하는 순간이 왔다.

바로 Resume 형식과 ResumeFile의 테이블 결과값을 합쳐야 하는 것!

왜???

지원하기도 그렇고, 이력서 탭을 클릭해서도 그렇고... 모든 이력서가 합쳐진 상태로 날짜순으로 정렬되어 보이게 된다. 그럴려면? 둘의 querySet을 합쳐서 order_by를 해줘야겠다고 생각이 들었다!

코드 보기 👀

위의 코드를 보면 resumes 변수와 resume_file 변수에 values를 사용해 특정 부분만 골라내는것을 볼 수 있다.

나는 union을 사용해서 합쳐주었는데, 서로의 형식이 다르면 합쳐지지 않기 떄문에 특정 부분만 골라서 합쳐주었다.

그리고 for문 안에 있는 introduce와 file_url을 보면 해당 값이 있으면 해당 값을 불러오고, 아니면 빈 스트링을 지정해두어 Frontend가 값을 받아 분기처리로 파일형식인지 아닌지를 판별 할 수 있게 하였다.

미래의 나... 보고 있나??ㅋㅋㅋㅋㅋ

사실 이 코드가 맞는 코드인지는 잘 모르겠지만.. 미래의 내가 이 코드를 보며 "멍청이!"라고 욕한다면 그만큼 성장했다는 뜻이니.. 미래의 뿌듯함을 위해 여기에 박제한다...ㅎㅎ

오늘은 나를 수없이 괴롭힌 친구를 리뷰하는 시간이다.. 이 친구는 여러 시리즈가 있지만.. 이건 그 첫번쨰 시간이다!

prefetch/select - related는 무엇일까?? 우리가 흔히 filter를 사용하여 쓰는 것을 좀 더 빠르게 작동해 줄 수 있는 기능을 제공한다. 어떻게? DB HIT(DB에 접근하는 행위)를 줄임으로 인해서!

더 자세한 사항은 곧 블로깅을 마련하여 설명하도록 하고 어떻게 적용했는지 살펴보겠다!

들러야 하는 DB Table이 많다....

일단 Posting을 뽑아야 한다. 근데 들러야 하는 DB Table이 너무 많다!!

나열해 볼까...?

• CompanyDetail
• Company
• State
• County
• CompanyImage
• CompanyTag
• JobCategory
• TagDetail

등등...

그럼 이것들을 연결해서 한번에 쫙~ 뽑아보겠다!!

이렇게 정리해줬다!

query가 뭐냐구?? 지금은 대충

Posting.object

이렇게 기억을 해두자! 더 자세한건 나중에 나를 진짜 괴롭혔던 코드로 돌아오겠다.....🔥🔥🔥

진짜 줄었어? DB HIT???

위와같이 비교했을떄, 200줄 -> 44줄이 되는 혁명적인 코드가 되었다!!

WOW!!

진짜 한줄이라도 줄면 다행인건데 이렇게 확?! 좋았어!! prefetch/select - related 너네, 내 동료가 되어라! 😎

2번째 프로젝트는 이래저래 사건도 많고 PM이된 내가 처음 이끄는 프로젝트여서 긴장도 걱정도 되지만 잘 헤쳐나가기로 다짐했었다! 하지만 새롭게 적용한 기술들이 많아서 중간에 다른 블로깅을 할 시간이 없었다🥲

후기를 먼저 올리지만... 기회가 된다면 이 프로젝트에서 적용했던 부분도 블로깅으로 남겨두고 싶다!

원티드? 우리는 원트어스!!😆

wanted 클론 사이트인 우리 사이트를 이름은 wantus로 정했다.

팀원은 Frontend 3명, Backend 3명으로 이루어져 진행했고, Agile 방식을 적극 활용하여 주마다 Sprint Meeting를 진행하여 한주간 어디까지 달릴지 설정했고, 매일 아침 Stand-up Meeting을 하여 어제 하루동안 한 일, 오늘 하루동안 할 일, 그리고 작업을 막는 블로커를 나누면서 소통을 하였다.

또한 Notion을 적극 활용하여 팀원들간의 data key값을 맞추었고, 회의 내용 또한 공유하며 소통하려고 애썼다.

DB 설정! 이번에는 29개...☠️

이번에는 테이블이 정말 복잡했다... (1차 프로젝트가 간단한거일수도..) 그 개수는 무려 29개! 심지어 우리는 한정적으로 구현을 하는 것에도 그 방대한 양에 놀랐고, 그 복잡한 화살표 관계를 따져보는것도 우리의 작업속도를 방해하는 블로커 중 하나였다..

(AqueryTool로 보러가기! pw:lgirvo)

구현한 범위

우리는 위와 같은 페이지로 구현을 하기로 했다. 아무래도 2주간의 짧은 시간동안 구현을 해야하기에 모든 페이지를 자세히 다루기는 어려웠던 부분이었다😂

하지만, 짧은 시간에 비해 우리는 정말 많이 배웠고, 소통했고, 잘했다고 생각한다!

그대로 따라하는 것이 아닌 기획까지 추가👍

우리는 기존의 사이트를 보면서 의아했던 점이 있었다. 바로 좋아요를 한 채용공고와 북마크를 한 채용공고의 UI가 같다는 것!

굳이 이렇게 같을 필요가 있었을까?

북마크는 더 자세한 정보를 알고 싶어서 북마크를 한 것인데.. 그러기엔 한눈에 전달하는 정보가 너무 단순했다. 그래서 기존 정보에 더해 어떤 직무의 직군의 마감일, 태그들도 함께 보여줬다.

Backend의 새로운 기능??

여러가지가 있어 하나씩 차근차근 설명을 하도록 하겠다!

• Unit Test 모든 View에는 unittest가 필수적으로 적용되었다. 그 전까지는 httpie를 이용해서 진행하였는데, 비용문제로 가장 작은 단위인 unittest를 이용한다는 말을 듣고 잘 적용하려고 애썼다. 이건 무려 1700줄...

• prefetch, select related 채용 리스트를 맡아서 진행할 때, 많은 DB를 hit하는 이슈를 해결하기 위해 사용했었다. 결국 200줄에 달하는 query문이 44줄로 줄어들게 되었다!

• 소셜로그인 카카오 API중 하나인 소셜로그인을 구현했다.

• paginator 원티드의 채용리스트는 무한스크롤이 되어 있다. 해당 기능을 따라하기 위해서 paginator를 사용했다.

• AWS

  • EC2 RDS를 연결하기 위해 꼭 필요했고, 배포를 해보고 싶어서 도전하게 되었다.
  • RDS 배포를 위해 이번에 새롭게 적용하여 올려보았다.
  • S3 우리의 핵심 구현중 하나인 파일 이력서를 올리는데 반드시 필요한 기능이였다!

후기 😎

이번 프로젝트에서 PM을 맡아서 진행하게 되었는데, 처음에는 그 무게가 그렇게 크게 느껴지지는 않았다. 처음에는 말이다... 처.음.에.는.ㅋㅋㅋㅋㅋㅋㅋㅋㅋ😂

프로젝트를 진행할수록 멘탈이 무너져도 그것을 티내지 않아야 했고, 누구보다 성실히 임해야했고, 팀원들을 배려해야 했다.

뭔가 욕심을 내면 안될꺼 같았고, 뭔가를 해줘야 할 것 같았다. (간식이라던지.. 간식이라던지... 간식...)

물론 위의 것들을 완벽히 이행했다는 소리는 당연히 아니다.... 오히려 다른 팀원분들보다 못한것도 있다. 하지만 그 부담감과 무게감이 팀원이었을때와 다르다는것은 확실히 느꼈었고, 그것이 나한테 영향을 준것도 분명한 사실이었다.

우리는 코드카타처럼 총 3명의 백엔드끼리 모여 많이 해봤던 기능들은 모여서 함께 구축했다. (네이게이터, 드라이버) 그 후에는 각자 안해본 기능들을 맡아서 서로 공유하면서 짰었는데, 후반으로 가니 각자 할께 바빠 코드들을 잘 보지 못한 것 같아 아쉽다...😭

특히 나의 경우엔 채용 리스트의 다중 필터 기능들을 구현하는데 어려움을 겪었다. DB 테이블의 지옥에 빠지기도 했고, 팀원간의 소통이 잘 되지 않아 새로운 데이터를 view에 추가하다 보니 unittest도 새로 짜고.. merge받는데 한세월이고...

돌이켜 보면 배움이고 희극인데 왜 그 당시에는 그렇게 비극이고 자괴감의 연속이었는지 모르겠다.... 이렇게 끝났으니 할 수 잇는 말이겠지??ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이 자리를 빌어 우리팀원들에게 참 고맙다고 말하고 싶다. 부족한 PM이었는데, 나를 믿고 다들 각자의 자리에서 최선을 다해주었다. 덕분에 좋은 결과를 얻었고 좋은 마음과 꺠달음을 얻을 수 있었다.

그리고 이 힘든 기간을 보낸 나에게도... "참 잘 버텼고, 버틴만큼 성장했고, 성장한 만큼 너의 미래는 밝다!!" 라고 말해주고 싶다 😁✌️

내가 무엇이 부족하고 무엇을 채워야 하는지 알게 되는 시간이었습니다. 부족한 PM 밑에서 고생 많으셨습니다 여러분!!

그리고 이제 곧 취업전선에 뛰어들 동기분들에게 아래의 말을 전한다!

WECODE에서의 첫번째 프로젝트가 끝이 났다. 첫 프로젝트였던 만큼 어려웠던 점도 아쉬웠던 점도 있는것 같다. 우리팀, 그리고 나의 2주간의 대장정(?)을 여기에 남긴다!

• 완성된 사이트 구현영상 보러 가기!
• 기술문서 보러 가기!
• 모델링 보러 가기! 비밀번호:818ycs
• git-hub 보러 가기!

사용 했던 기술 스택

• Python
  • python shell
• Django
  • ORM
  • json
  • http method
  • Views, Models
• MySql
• RESLful
• bcrypt, pyjwt
• Vim, VScode
• httpie
• minicomda
• slack, git hub, trello

Agile

우리는 철저히 Agile방식을 사용하여 시작을 하였다. 밑에서 천천히 어떤 방식을 적용하여 시작했는지 적어가겠다!

초기 세팅

우리는 Frontend는 CRA로 초기세팅을, Backend는 django를 활용한 초기세팅을 진행했다.

Django와 React로 처음하는 프로젝트라 그런지 초기세팅조차 쉽지 않았다. React는 ESLint와 Pretire 에러의 늪에서 헤어나오느라 허덕였고, Django 또한 miniconda, mysql, my_settings.py 설정 등등에 힘겨웠다.

Git-hub를 설정할때는 .gitignore의 존재를 잊고 있다가 뒤늦게 발견해서 repository를 하나 날려버리는 헤프닝도 발생했었다.ㅋㅋㅋㅋㅋㅋㅋ😂😂😂😂😂

slack과 trello, git-hub repository로 커뮤니케이션을 했다. 끊임없는 회의를 하기보단 trello를 보며 project flow를 파악하려 노력했고, 코드공유 또한 git-hub를 통해 이루어졌다.

Goal Setting

매주 월요일에 스트린트를 지정하여 한주간 달려야 할 지점을 정했고, 매일 오전 10시 30분에 스탭드업 미팅을 해서 하루의 목표도 설정했다.

우리의 프로젝트는 총 2주에 걸쳐 진행되었다. 작업 진행 방향성과 우선순위는 Frontend의 UI가 나오는 순서대로 View를 뽑아내서 맞춰가는 방향으로 설정했다.

지옥의 Modeling의 1주차...

1주차에는 필수구현에 집중했다.

• Main
• SignUp
• Login
• Product List, Detail
• Cart
• Payment 이상 7가지 UI와 View를 뽑기로 설정했고, 실제로도 잘 구현되었다.

그리고.... 잘 구현됐다는 이야기는 Frontend에만 해당되는 이야기다😂😂😂

Backend의 Modeling...?

아니, 정말, 이래도 되나 싶을정도로, 모델링이 오래 걸려도 되나 싶었다. (왜 자꾸 수정 할 것이 트어나으느거야....)

단순히 모델링을 하는데 오래걸렸다는 이야기는 아니다. 팀원들과 회의를 하며 모댈링을 했을때는 완성까지 모든 힘을 쏟아부어 3-4시간만에 완성이 되기도 했다. 그래서 의자에 힘없이 늘어져 있었는데 우리 프론트 팀원분이 "우리 팀 백엔드분들만 노는것 같아요."라며 말씀을 하셨다ㅋㅋㅋㅋㅋㅋㅋ (지금까지 공부하다가 잠깐 쉴때 엄마가 보더니 혼냈을때.. 그런 느낌이었다...☠️☠️)

근데 직접 데이터를 넣고 view를 짜다 보니

"어...? 이거 왜 없지?" "어? 이건 또 왜 unique/null=True가 아니지?" "이러면 이것을 참조하는 테이블이 하나 더 필요한데...?"

하는 의문들과 함께 완성했다고 생각했던 모델링의 무한수정이 펼쳐졌다. 언제까지? 다음주 화요일까지...

물론 다른 view들도 나왔었지만, 가뜩이나 csv파일도 늦게 만드느라 models.py수정하고 DB날리고 makemigration, migate 다시하고..

딜레이의 연속이었던것 같다.

그래도 점점 완성되어가는 2주차!

어쨋든 시간은 흐르고... 점점 모습을 갖추며 완성이 되어가고 있었다.

어려웠던 부분이 있다면?

단연컨데 OrderListView라고 말할 수 있을 것 같다. 이게 딱 찝어서 뷰만 그렇다고 할수는 없고 그 시스템을 이해하는것이 어려웠다..

자세한 내용은 이 블로깅을 참조...

마음의 부담이 점점 커졌다☠️

프로젝트를 진행할수록 마음의 부담이 커져갔었다. 힘들어하던 도중에 이런 생각이 들었다.

"즐기면서 할 수 없을까? 난 왜 이렇게 힘들게 코딩을 하려 하지?"

그 순간부터 무언가를 내려놓고 시작했다. 프로젝트에 대한 마음과 노력을 내려놓은 것이 아닌 내 부담감을 내려놓았던 것 같다. 그런뒤부터 지금까지 부담없이 "재밌게!" 잘 코딩을 하고 있다ㅎㅎㅎ

후기

처음 WECODE를 왔을때만 해도 "나는 한번 코딩을 배웠었는데, 너무 의미없는 시간이 아닐까..." 생각을 했었다.

그치만, 1차 프로젝트를 하고 난 뒤에 확실히 "아니다"라고 말할 수 있다.

팀원들과 소통하는 커뮤니테이션, 나 스스로 코드를 돌아보는 코드리뷰, 멘토님들이 지적한것들을 다시 짜보는 리팩토링, 그리고 다른 동기들과 부딪히며 얻는 긍정적인 모든 것들이 너무나 소중하다.

난 2주간 부족했지만 WECODE에 있었던 어떤 시간보다 제일 많이 성장한 시간이라고 생각한다.

나는 완벽주의자다. 그래서 그런지 나의 성향에 우리 팀원들이 많이 힘들지 않았을지 많이 미안하다. 그리고 이런 나에게 너무 잘한다며 무한 칭찬을 패시브로 장착하며 같이 달려온 팀원들과 동기들에게 너무 감사하다!😭

개발자는 끊임없이 자기 개발을 하고, 도태되면 안된다고 하던데 끊임없는 구글링과 마인드 컨트롤을 하며 달린 이 2주간은 정말 그랬던것 같다. 지금 프로젝트가 끝난 이 시점에도 여기서 도태되지 않고 어제보다 나은 내가 되며 나아가고 싶다.

그렇게 힘차게 나아가다 뒤를 돌아봤을때 이 글을 보며 흐뭇해하는 내가 되어 있길 소망하며 오늘도 JUST DO IT!

머리속으로 그려보기☀️

메인페이지를 보면 잘나가요, 새로 나왔어요, 지금은 할인 중이라고 나눠져 있고, 각각 4, 8, 8개의 상품으로 이루어져 있는것을 알 수 있다.

이것들을 객체에 담아 넘기면 되겠다!! 라고 생각했다.

실제 코드 짜기🚀

compare_date는 날짜를 비교하기 위해 필요하다.

check_best_list는 베스트인 상품들의 배열이다. 베스트 상품은 전체 상품 중에 제일 잘 팔린 상품들의 20개다.

각각의 4, 8, 8개의 상품을 얻어야 하는데 이것은 상수로 지정하여 유지보수가 편할 수 있도록 설정하였다.

각각의 쿼리를 필터링하는 조건과 방법은 다르지만, 다 비슷비슷하게 작성되었다. is_new는 create_at을 기준으로 한달 이내의 제품만 True가 되게 하였고, is_best는 해당 제품이 위에서 구한 best_list에 in되어 있는지 검사하였다. 모든 제품의 sale값은 0이 default인데, is_sale은 0보다 크면 True가 나오게 하여 각각의 항목에 대하여 나눠주었다.

드디어 그 끝을 맺은 DB! Aquery를 이용해서 완성을 했다...

DB 모델링 과정

우리의 DB 완성이 오래 걸린것은 아니다. 처음 DB는 3시간만에 나오기도 했었는데 그것의 수정의 수정의 수정의 수정의....

무엇이 오래 걸렸는지...

1. ForeignKey의 관계가 너무 복잡..
   • user와 product의 관계가 너무 많이 물려 있었다...
   • related_name 지옥..
2. 제약조건의 수정수정
   • 진짜 처음에는 account에 unique도 주지 않고 있었다ㅋㅋㅋㅋㅋㅋ
   • 생각보다 null=True, default=가 많이 있었다.
3. 논리적인 문제!
   • 이 컬럼이 이 테이블에 있어도 되는 것인지,
   • 이렇게 해서 이 데이터를 구할 수 있지만 이 테이블에 그냥 넣어주는게 어떤지 등에 대한 문제들
4. 그냥 우리의 실수
   • 사실 이게 대부분...ㅋㅋㅋㅋㅋㅋㅋ

느낀점..

진짜 다음에 모델링을 하게 되면 제약조건만은 꼼꼼히 따져서 하고싶다. 빼먹는 실수 없기, 깔끔하게 짜기 꼭 기억!!

머리속으로 그려보기☀️

실제 사이트를 보면 해당 마이페이지에는 3부분으로 나눌 수 있게 되있다.

• Aside
• Header
• Article

나는 그중에서 Aside, Header를 공통 컴포넌트로 만들고, Article은 menu tab형식으로 url은 안바뀌지만 컴포넌트는 계속 바뀌는 형식으로 만드려고 한다.

실제 코드 짜기🚀

clickHandler()

clickHandler()는 해당 카테고리를 클릭했을때 실행된다. 각 카테고리는 key값으로 고유한 id를 가지고 있기 때문에 구분해서 나타낼 수 있다.

MAPPING_OBJ

고유한 id값으로 MAPPING_OBJ에 index로 접근을 한다. setState로 currentId로 바꿔주기 때문에 바뀔때마다 Component만 바꿀 수 있다.

Component 각각에는 render 될때 fetch로 필요한 데이터를 받기 떄문에 독립적으로 실행될 수 있다.

머리속으로 그려보기☀️

위와 같이 카테고리 탭을 누르면 query parameter로 전달이 되고 fetch가 되어야 할 것 같다.

근데 카테고리 자체가 component이며 아래의 product list도 component이다. 이 둘을 어떻게 연결시켜서 productList를 받을 수 있을까...

실제 코드 짜기🚀

어떻게 해야할지 멘붕의 연속이었다. 뭔가 어거지로 껴 맞춰서 한 느낌이 없잖아 있지만.. 과거의 나를 보며 웃을 미래의 나에게 보내는 블로깅이다....ㅋㅋㅋㅋㅋㅋ

Nav.js에서는 url만 바꿔주기!

각 카테고리별로 누르게 되면 menuChange() 이벤트가 발생한다. 파라미터로는 id를 받는데 이 id란 각 카테고리의 한글이름이다.

따라서 이 menuChange()가 실행되면 /product?category=문구 같은 형식이 된다.

ProductList.js!!

ProductList.js에서는 바뀐 url를 기준으로 진짜 fetch를 보내 productList를 받는다.

이 productList는 state중 하나로 설정하여 바뀌면 reRender가 되게 한다. getProductList()를 만들어서 현재 주소에 대한 리스트를 받는다.

componentDidMount()

처음 카테고리를 선택해서 실행하게 되면 해당 이름이 고정된다. 예) 전체 누르면 category='전체'

componentDidUpdate()

처음 카테고리를 누른 상태에서 다른 카테고리로 가면 fetch를 실행하는 로직이 없기에 변화가 없다.

그래서 componentDidUpdate를 만들어서 현재 category값과 다르다면 getProductList()를 다시 실행하고 setState를 현재 category값으로 변경해준다.

이번에 볼 코드는 MyPage중에서도 메인이다. 비록 우리 프로젝트에서는 시간관계상 구현을 하지 못한 부분이지만, View로는 구현을 해놨었다!

머리속으로 그려보기☀️

마이페이지 메인에는 보여줘야 할 부분이 많은것 같다.

1. 사용자 이름, 회원등급
2. 쿠폰, 적립금
3. 진행 중인 주문(order_status, product_status)
4. 최근 주문 정보
5. 최근 본 상품

하지만 여기서 우리는 최근 주문 정보는 생략하고 나머지를 구현하기 결정했고, 그것을 제외한 것을 다 객체 key/value로 보내줘야 할 것 같다!

실제 코드 짜기🚀

my page header

이 부분은 유저의 이름, 등급, 포인트, 쿠폰이 들어가는데 각각의 테이블이 존재해서 해당 테이블에 접근해서 count(), first(), request.user를 이용하여 이름과 등급을 구해주었다.

order status

이것도 간소화하여 진행을 하였는데, 입금대기와 같은 상태들만 나타내서 보여주기 하였다.

하지만 그 과정은 절대 쉽지 않았는데...

order_status별로 카운팅을 하는 ORM을 짜는것이 쉽지 않았다.

나는 SQL문이 더 익숙해서 먼저 SQL문으로 짜보고 난뒤 group_by()와 annotate(), count()로 구현을 했다.

recently view

어차피 이 공간에는 상위 4개만 들어가기 때문에 4라는 숫자를 상수로 지정해서 사용했다.

생성된 날짜순으로 order_by()사용했고, distinct()를 사용해서 중복값을 제거하고 나타내주었다. (동일한 상품이 나오면 안되니까!)

이제 프로젝트의 끝 마무리가 다가온다. 오늘은 저번에 이어서 주문된 상품에 대하여 구매확정/배송중/입금완료 등과 같은 order_status를 담고, 각 상품에 대한 취소/반품/환불/구매확정의 상태를 말해주는 order_product_status를 담고 있는 order_list를 리뷰해 보겠다.

머리속으로 그려보기☀️

저번과 마찬가지로 물품을 구매하지 않아서 어떻게 로직이 구성되어 있는지 알 수 없었다. 그래서 생각으로 이렇게 되어 있지 않을까... 하며 로직을 짰다.

우선 나는 아래의 것들에 유의하며 코딩을 했다.

• 입금대기/입금완료/배송중/배송완료의 order_status가 있다.
• 배송완료가 된 주문들에 한해서만 취소/환불/교환/구매확정을 할 수 있다. 이것은 product_status이다.
• 구매확정을 하면 해당 status 값을 변경해준다. (PATCH)
• 변경해주고 review를 쓸 수 있게 하고 등록하게 한다.
• 쓴 리뷰는 바로 이동하여 볼 수 있게 한다.

하지만 내 코드는 시간의 부족상 취소/환불/교환 같은 status를 바꿔주는 로직은 작성하지 못했다...😂

실제 코드 짜기🚀

GET은 저번시간의 get_order_list!

GET method는 저번과 같다.

POST가 아닌 PATCH?

좀 더 RESTful한 방법이 뭘까 고민했다. PUT과 PATCH가 생긴 후론 POST는 생성에 집중되는 것 같다. 그래서 단순히 status를 변경해주는 것은 PATCH로 했다.

이번 코드에서는 status=4로 변경하게 했는데.. 이 부분이 참 아쉽다. 4번은 구매확정이다.

머리속으로 그려보기☀️

리뷰는 상품을 사야만 쓸 수 있어서 이번 코드는 내 머리속으로 구현을 해 보았다!

일단, 별점이 있고, 제목이 있고, 내용이 있다. 아이디를 받고 create_at이 있는것 같다.

상품을 구매하고 별점을 쓰게 하려면, 일단 다음의 순서가 필요할 것 같다.

1. 상품을 구매한다.
2. 구매확정을 한다.
3. 구매확정이 된 주문에 한해서 리뷰를 쓰게 한다. (review와 order를 이어주는 matching_review테이블을 만들어서 동시에 create해준다.)
4. 이미 matching_review에 연결된 review가 있다면 리뷰를 못쓰게 한다.

이것을 바탕으로 POST를 중심으로 코드를 짜보도록 한다.

실제 코드 짜기🚀

GET은 그냥 뿌려!

request.user를 통해 user_id값을 받고 그것을 list comprehension을 통해 Json으로 보내준다.

자... 천천히 해보자 POST

일단 matching_review테이블에 product_id와 order_id를 가지고 있는 데이터가 있는지 확인한 후 없다면 review를 쓰게 한다.

잠깐, Transaction?! 왜????

두가지 상황을 막기 위해서다.

1. review에 글을 썼는데, matching_review에 안쓰였다면, review를 또 쓸 수 있게 한다.
2. review를 안썬느데 matching_review에 데이터가 있다면 review를 쓰지도 못한다.

그레서 두 테이블에 모두 데이터가 정상적으로 등록이 될때만 데이터가 등록되도록 설정을 한다.

get_order_list?

리뷰를 보여주는 목록은 상품 디테일 페이지에서도 보여줄 수 있지만, My Page에서도 연결시켜 줄 수 있기에 코드의 재사용을 줄이려 함수로 선언하고 사용했다.

머리속으로 그려보기☀️

배민의 경우에는 좀 독특한 방식의 찜하기를 지원하고 있다. 위에서처럼 하트를 누르는 동시에 찜리스트 목록으로 이동한다.

그리고 마치 생김새도 장바구니의 하위 호환처럼 생겼다. (내가 생각한 찜목록과 전혀 다르다!)

이것을 구현하려면, 또 RESTful하게 하려면, GET과 POST를 한번씩 해야하는건지, 아니면 POST/GET에서 다른 것의 역할까지 해야하는지 많은 고민을 했다.

*결국 Frontend에서 두번 요청하는 것으로 *하였다.

실제 코드 짜기🚀

일단 찜 기능은 회원을 타겟으로 한 기능이기에 login-decorator기능을 활용했다.

My Page에서 볼 수 있는 GET

일단 로직자체는 간단하다. 로그인을 성공하면 login-decorator에서 request.user에 payload에 담긴 정보를 담아준다. (유저 id)

그것을 바탕으로 productlike_set을 활용하여 모든것을 가져온다. (user와 productlike는 M2M 관계다.)

하트를 눌렀을때 delete_or_create

찜을 처음하는 상품이라면 당연히 create를 하지만, 이미 찜한 상품이라면?! 그럴땐 언팔의 기능처럼 찜을 취소해야 할 것이다. 그래서 이미 있는 상품에 대해선 delete를 시켜준다.

상황 🧑🏻‍💻

프로젝트를 진행하던 도중 만난 에러🚫🚫🚫 Frontend가 new라는 이미지를 붙여주는 조건부 랜더링을 위해, MainView에서 오늘 날짜와 product의 create_at의 날짜를 비교하여 나타내주어야 했다.

🚨오류🚨

datetime.today()과 create_at을 비교하는 isNew()함수를 실행하니 다음과 같은 에러가 나왔다.

💡해결💡

구글링을 통해 알아보니 결국은 이 문제다. offset-naive타입과 offset-aware타입이 같지 않아서 연산을 할 수 없다....?

그러니까.. offset-naive에는 날짜와 시간 정보만 담겨 있다. 근데 offset-aware은 날짜와 시간정보는 물론, 어디 지역에서 생성한 날짜 데이터라서 GMT+9라는 지역 정보까지 저장된다는 것이다.

실제로 django에서는 offset-naive 사용을 지양하고 offset-aware만을 사용하길 권장하고 있다.

그래서 나는 아래와 같이 해결하였다.

Error를 해결하고나서 느낌 💣

오늘도 또 한차례 성공했구나.. 싶었다. 근데 이게 바쁜 프로젝트 중에 발생을 하여 귀중한 시간을 까먹으니 참 답답했다....

나와 같은 상황이 발생되지 않게 아래와 같이 slack에도 동기들과 공유도 하였다...❗️ 😎

이 글에 유입된 모든 분들도 저로 인해 시간을 아끼셨으면 좋겠다...!!!

WECODE의 2달차가 시작되었다! 그리고 내 팀은 배민문방구를 클론하는 걸로 정해졌다.

그래서 이름은? 이백문방구! (http status 200길만 걷자 해서 지어진 이름ㅋㅋㅋㅋ😁)

project를 하며 가지는 개인적인 목표🚀

Backend

• [Modeling]
  • M2M 방식의 through, related_name을 이해 및 활용
  • foreignKey로 연결된 관계를 이해하고 CRUD 적용
• [View]
  • 다양한 CRUD 메소드 활용(__gt, only(), order_by(), distinct() 등...)
  • RESTful 방식을 활용한 http 활용
  • Query parameter 방식 이해 및 활용
  • Path parameter 방식 이해 및 활용
  • json 방식의 이해 및 활용
  • list-comprehension 방식 이해 및 활용
  • 다양한 ORM method 이해 및 활용
• [CSV]
  • csv 파일을 이용한 database data inserting

Frontend

• [React]
  • class component 적용
  • call-back 함수를 이해 및 활용
  • state, props 개념 이해 및 활용
  • mock data 이해
  • fetch를 통한 통신 써보기
• [SCSS]
  • nesting 이해 및 활용
• [Flex]
  • 다양한 속성들 활용

공통

• git-hub의 익숙해지기
• git-hub 컨벤션에 따라 commit, push 하기
• trello를 통해 분담시스템 적응하기
• asile 방식으로 사이트 구현하기

내가 맡은 부분은~? FullStack!

사실은 Backend지만, 나는 사실 설연휴때 react를 공부했다!(욕심쟁이...ㅋㅋㅋㅋ)

그래서 이번 프로젝트에서 두 영역다 맡아서 진행하고 있다. 내 개인적인 욕심으로 인해 다른 팀원분들이 피해를 받지 않게 하는 것도 이번 프로젝트의 목표 중 하나이다!

더 자세한 사항은 기술문서에서 확인해주세요~ (PM희영님 감사합니다~)