[PROJECT 1주차 - 2] 회의록 및 간단한 회고

전날 하나의 디스코드 팀 채팅 채널에서만 회의를 진행하고 사안들을 공유하니까 백엔드와 프론트엔드의 안건들, 각종 링크들이 섞여서 가독성이 많이 떨어지는 것을 확인했다.. 따라서 22팀 전용 디스코드 서버를 새로 파 백엔드/프론트엔드 채널을 나눠 회의하고 안건을 주고받았는데 이전보다 더 편해진 것을 느꼈다!!

기존 채팅방은 주요 공지방으로!

 

구글링해서 찾은 이미지 - 우리 서버 타이틀!

 

오늘은 팀원분들과 처음으로 오프라인 만남을 가진 날이었다.

선릉역에 있는 엘리스 미팅장을 미리 대여하여 12시에 만나 회의를 하고 각자 코딩하였다!

 

오늘은 각자 분배받은 역할을 확고히 하였고, 프론트엔드에서는 주로 스켈레톤 내에서 반복되는 html 코드(헤더 (nav) 부분)를 모듈화 시키고자 하는 회의, sass, ejs, pug 같은 걸 활용해 코드를 작성해도 될지에 대한 회의 및 문의사항 정리를 하였다.

 

https://developer.mozilla.org/ko/docs/Web/API/Element/insertAdjacentHTML

Element.insertAdjacentHTML() - Web API | MDN

insertAdjacentHTML() 메서드를 활용해 중복되는 헤더 부분의 HTML 코드를 떼어 모듈화 시키고, html을 작성할 때마다 모듈을 불러오는 형식으로 작업하고자 했다.

 

document.body.insertAdjacentHTML(
  'afterbegin',
  `<nav class="navbar" role="navigation" aria-label="main navigation">
<div class="container mt-3">
  <div class="navbar-brand">
    <a class="navbar-item" href="/">
      <img src="/elice-rabbit.png" width="30" height="30" />
      <span class="has-text-link">쇼핑-n팀</span>
    </a>

    <a role="button" class="navbar-burger" aria-label="menu" aria-expanded="false" data-target="navbarBasicExample">
      <span aria-hidden="true"></span>
      <span aria-hidden="true"></span>
      <span aria-hidden="true"></span>
    </a>
  </div>

  <div class="navbar-end breadcrumb my-auto" aria-label="breadcrumbs">
    <ul id="navbar">
      <li><a href="/login">로그인</a></li>
      <li><a href="/register">회원가입</a></li>
      <li>
        <a href="/cart" aria-current="page">
          <span class="icon">
            <i class="fas fa-cart-shopping"></i>
          </span>
          <span>카트</span>
        </a>
      </li>
    </ul>
  </div>
</div>
</div>
</nav>`,
);

<script src="../template.js" type="module" defer></script> // 이 형식으로 html 상단에 주입

 

아침 스크럼 이후 약간 늦은 점심을 먹고 오후 커피 한잔 하고 다들 귀가하였다.

 

---

 

회의록

 

<스크럼 안건>

1. 프리토킹에 공지된 사안 2가지 변경하기(되도록 만나있는 상태에서 진행)(완료)
2. 어제 분배한 만큼의 작업 완료하기
<작업시 주의사항(프론트)>
    1) nav 바는 script 추가
    2) dev-front layout 기준으로 페이지 작성

3. 어제 문의드린 내용에 대한 답변 확인(완료)
4. 상품판매 - 관리자가 올리는 것(User가 판매 불가능) / 판매자가 올리는 것(User 판매 가능) 
 => 관리자가 올리는 것으로
관리자 페이지(view 에다 admin 폴더 추가해서 만들 예정)
5. 카테고리 더 추가할 것인가?
 - 관리자 페이지에도 카테고리 만들고 추가하는 기능 추가됨
 - 카테고리 목록에 관한 db는 일단 간단하게 만드는 걸로

회원가입 페이지 - admin 코드 입력하는 input 란 하나 추가하기 input name=adminCode
(but 필수 입력이 아니도록 컨트롤해줬으면 좋겠음)


<프론트엔드 오피스아워>

1. [프론트엔드] package 관련
 - 넌적스를 사용하는 이유는? : 한번 세팅해 본 다음 괜찮으면 팀원들과 사용해보고 싶어서!
 - (다음 오피스 아워때 설명해 주시기로 함!)


2. [공통] Git tip
 1) Merge Request 이후 나중에 다시 작업할 가능성이 있는 branch도 삭제해야 하나요?
=> MR 했으면 commit들도 dev 브랜치에 merge가 된 상태이므로 dev 브랜치를 공유해주면 안되나?
feature branch는 삭제하는게 좋은가? - Yes!
반영한거 기준으로 새로 브랜치를 만들지 않고 계속 옛날걸로 작업하면 그 브랜치에 다른 분이 다른 커밋을 할 
수 있는거고 최신이 아닌 상태로 계속 작업을 하게 되기 때문에 완성을 해서 dev와 머지할 때 충돌 가능성도 있고
A기능을 개발할 때 팀원이 A를 더 발전시켜서 머지한다고 할 때, 업데이트에 어려움이 있을 수 있어서

보통 branch를 만들 때 가능한한 issue 단위로 feature branch를 새로 생성하는게 제일 바람직하다.
git을 사용하는 이유가 버전관리 이기 때문에 새로운 기능을 만들 때는 새로운 브랜치를 추가해서 하는게
바람직하다!!!
feature 단위를 잘게 자르되, 너무 작지는 않게 잘 조절해서 자르도록 한다.
기능에 대한 범위를 잘 정하고 작업을 하는 것이 관건.

2) dev branch 업데이트 내용이 있다면 작업하고 있는 feature branch에도 pull 받아서 반영해주는게 좋을까요? 
아니면 Merge Request를 진행하는 것이 맞나요?
=> pull 받아야 하는 상황이란? : ex> 공통으로 작업해야하는 상황 / 공지된 수정사항을 고치는 개념(Hotfix)
코치님이라면 dev branch에서 그냥 pull 받아서 진행하실 것 같다.
feature가 완료되지 않은 상황에서 pull 받아서 업데이트 시키는 상황이기 때문에 이 경우에는 pull 받는게 좋아보인다.
++ pull 받고 conflict 해결하고나서 conflict 해결한 commit도 남겨주는게 좋다!!!

3) git에서 백업 개념으로 feature 브랜치에 완성되지 않은 결과물들을 수시로 commit 하는 방식으로 작업해도 괜찮을지, 
그 방식으로 작업한다면 혹시 어떤 문제사항이 생길지 궁금합니다
=> commit을 하는 것의 장점은? : 이전 시점으로 돌아갈 수 있다.
commit을 작게할 수록 좋다! 돌아갈 수 있는 지점이 많아지기 때문!!!
but 수시로 ctrl+s 하듯이 commit 하는 것 보다는 기능의 의미 단위로 묶어서 commit 해주는 것이 좋다.
commit을 어떤 단위로 묶어서 하면 좋은지 정리해보면 도움이 될 것이다.
commit을 어떤 단위로 묶어 할지 팀 규칙을 정하면 좋다.
++ push 타이밍 : 더이상 뒤로 돌아갈 것 같지 않을 때 push를 한다! (코치님께서는 commit을 모아서 하시는 편)
굳이 1 commit 1 push 하지 않아도 된다.


3. [프론트엔드] 공통 레이아웃 (header, container) 작업
=> body에 붙인 이유는? : body 최상단에 들어가는 내용이기 때문.
 - body에 이렇게 붙이는 것 자체는 익숙하지 않은 방법이지만, 시도와 의도는 좋다. (자주 쓰이진 않음)
 - 시간이 좀 있다면 넌적스 쓰는걸 비추천한다. - 반복되는 기능을 컴포넌트로 어떻게 관리할 수 있을까를
라이브러리 없이 좀더 바닐라 JS로서 해봤으면 좋겠다고 생각한다. (JS 실력을 늘리기 위해)
그냥 기능 관리 측면에서 사용하겠다 하면 나쁘지는 않다! 좋다.

 - 타겟을 document.body 로 잡기보다는 queryselector로 잡아서 하는걸 좀더 추천한다.
시간이 더 있으면 좀더 찾아보고 어떠한 방향이 우리에게 맞을지 고려해봤으면 좋겠다.

++ sass 사용
=> css를 페이지별로 작성해 하나의 메인 페이지에 import 한 뒤 작업하는 방식 주로 사용.
 - 팀 규칙에 따라 하는거겠지만 views/assets/sass 하나로 관리 << 를 좀더 추천한다

sass 세팅해놨는데 start 했을 때 함수 실행이 안됨!!!
sass 관련 정리해서 민선님께서 올려주실 예정


4. 마크업 언어로 페이지를 전부 작성하고나서 어떤 기능 먼저 개발하면 좋을지 감이 안잡히는데 개발 flow에 대해서 Tip좀 부탁 드립니다!
=> 요구사항을 메인으로 4가지 대 주제를 잡고, 큰 영역들에서 어떤 기능들이 세부적으로 필요한지 리스트업 해보기.
 - 그 작은 기능들 사이에서 우선순위가 있을 것..
 - 최대한 대주제 안에서 소주제(feature)를 쪼개서 만들어 진행하도록 한다(이것이 issue!!!).
=> 어떤 기능을 개발해야할지 감이 안잡히는 이유 = 어떤 기능이 있는지 파악이 덜 되었기 때문에 그렇다!
팀원들과 어떤 기능이 있을지 파악해보는 시간을 가지는 것을 추천한다.

 

<추가 회의>
++ [프론트엔드 과제!] 본인이 마크업 제작한 페이지에 무슨 기능이 들어가야 할 지 리스트업(정리)해오기
 - 각자 리스트업 한 뒤 취합할 예정!! - 목요일 오후 12시까지

 

백엔드에서도 회의를 활발히 진행하는 것 같았으나 프론트엔드 회의에 참석하느라 참석하지 못하였다..

 

 

그리고 민선님께서 프로젝트시 참고하면 좋을 것 같은 글을 공유해주셨다. 기록용으로 블로그에도 남긴다!

 

https://velog.io/@1106laura/insertAdjacentHTML

JS로 DOM 요소를 삽입할 때 : insertAdjacentHTML

( comment : insertAdjacentHTML와 innerHTML 나눠서 쓰는 경우에 대해서 설명해주는 글인데 추후에는 innerHTML로 수정할수도 있을 것 같지만! 일단은 insertAdjacentHTML로 적용해주겠습니다! 한번 읽어보면 좋을것같아서 공유합니다! )

 

https://d0gf00t.tistory.com/20

[번역] CSS개선을 위한 SEM과 BIO의 결합

( comment : 저는 개인적으로 저런식으로 실무에서 css 구성을 했었는데요. 스타일에 관심 있으시면 그냥 한번 쓱 읽어만 보시는걸 추천합니다! 
저걸 그대로 사용할껀 아니예요!! (=> 시스템 구축이 오래걸리니깐요!!) 한번 읽고 scss 폴더 구성을 보면 좀 더 좋을 것 같아서 남겨둡니다! )

 

민선님께서는 퍼블리셔로서 오랜 실무 경험이 있으신 분이라 곁에서 많은 배움을 얻고 있어 감사하면서 따라가고 있는 중이다.. ㅠㅠㅠㅠ