오늘의 스크럼
- 각자 와이어프레임 수정한 거 돌아가면서 설명
- 날씨 컨셉 살려서 평점은 아이콘을 쓰면 좋겠다고 제안 -> 공통 아이콘 결정
- (나) 어제 알게 된 JSDoc 기능 하나를 소개
텍스트 에디터 자체에 있는 기능으로, 함수 위에/** */이런 주석을 달면 해당 함수 작성 시 마우스를 대면 주석이 같이 뜬다.
이제 각자 맡은 페이지 UI layout을 시작하는데 생각해보니 라우터 준비가 안 되었다. 어제 API 작성하면서 뭔가 중요한 걸 빼먹고 다음 단계에 도달한 느낌이었는데 찝찝함이 이거였던..
모두에게 공통 부분이니까 디펜던시 작성할 때 함께 작성해서 올리는 게 나았겠다!
기획 단계에서 했으면
-
VSCode 터미널에서 원하는 위치에 폴더 생성
mkdir 플젝명 -
cd 플젝명 -
npm init -y: package.json 생성됨 -
디펜던시 설치(express, ejs, express-session, crypto, multer, mysql2, sequelize, sequelize-cli)
-
MVC 패턴으로 폴더 구조화
-
라우터, 컨트롤러, 미들웨어 등 서버 설정
API 설계 짜면서 전체 흐름을 한 번 훑어볼 수 있었어서 의미있다고 생각하긴 하는데 비중을 좀 더 줄여도 되겠다. 어느 정도가 공통이고 어디부터 달라지는지 생각을 못했던 것 같다.
git conflict 발생
덜렁 css 폴더만 만들어 올리고 미들웨어 추가를 안 했다. 그럴 만도 한 게.. 라우터를 작성하면서 한꺼번에 폴더 구조를 생각해야 했는데.. 이걸 따로 하니까 빼먹고 헷갈림.
그래서 git push까지 하고난 후, pull request 보내려는 때에 conflict가 발생했다!
이런 식으로.
>>>>>>>>>>>HEAD
app.use("/static", express.static("static"));
============
app.use("/static", express.static("static"));
<<<<<<<<<<<새로운원인
같은 파일에서 같은 부분을 건드리는 바람에 생긴 충돌.
해결
resolve conflict 클릭 후 중복된 부분을 지워주고 commit change를 눌러주면 간단히 해결할 수 있다.
git으로 협업하기 - branch 위주
- Repo 생성 : rule, default branch 등 기본 세팅까지
- 조원 초대 : settings - collaborators - add
- 조원 모두 : 각자 맡은 feature의 branch 생성 ex. feature/main
- 열심히 코딩
git add->git commit->git push origin feature/main- PR 생성
이렇게 사이클이 돌아간다. merge를 하면 remote에서는 (setting 해뒀다면) 곧장 branch는 사라진다. 로컬은 직접 지워줘야 함. git branch -d 브랜치명
다시 작업 시작하면
- 터미널에서 프로젝트 폴더로 위치 이동
- default branch(ex. develop)에서
git pull
(default branch 이용 시엔 origin 필요 없음! 이미 origin이니까) - 작업 branch 새로 생성 :
git checkout -b 새 브랜치명 - 다시 열심히 코딩 후 반복
오늘 한 것
- routes/ controller/ index.js 만들어서 서버 Open
- 내가 맡은 프론트 페이지(main, header, footer, search) 일부 작성
main.ejs
윈도우에서 보다가 맥으로 보니 완전 다르다.. 코멘트 박스의 코멘트 부분 margin-bottom이 매우 좁군. 그리고 section title의 width도 작게 보이는 듯하다. 노트북 항상 들고가서 왔다갔다 하면서 둘다 괜찮아보이는 지점을 골라야겠다... 이렇게 하는 게 맞나?
header.ejs
이미지 4개가 slide 1, 총 3까지 만들어야 하는 헤더 부분. 방법을 찾아봤는데 너무 복잡해서 일단.. 대충 쫘르륵 쓰기만 하고 거의 안 건드렸다.
footer.ejs
여기도 일단 글만 쭉 쓴 정도. b 태그 넣었는데 거의 뭐 보이질 않네.
search.ejs
뭘 작성하긴 했네..
main -> footer -> search -> header 순으로 레이아웃 완성해야겠다.
덧붙이는 말
1. 드디어 branch 개념 잡혔다
merge하면 branch 지워지는데 그럼 뭐하러 계속 다시 만들어야 하나 번거롭지 않나..? 싶어서 혼란스러웠다.
하지만 PC 환경이 계속 달라지기도 하고, 한번에 업데이트 왕창 하는 것보다 이슈 없을 때마다 조금씩 합쳐가는 게 더 낫다는 걸 경험으로 몸소 이해했다. (static 미들웨어의 교훈..)
merge 된 지점까지는 저장소에 있으니까 이후 작업이 조금 엉망이라도 회귀 포인트가 존재하는 느낌이랄까. 물론 로컬만큼 안전한 백업은 아닐지라도 어느 정도 믿을 만한 구석이 되는 듯하다! 게다가 코드 작성하는 중간중간에 디펜던시가 달라지거나 공통으로 작성할 것들이 생기니까, 한 번에 업뎃해주는 느낌으로다가.
2. 에러는 생각보다 사소한
git이나 에러 발생할 때 구글 검색하면 되게 짤막한 해결들이 많아서 궁금했었다. 이렇게 손쉽게 해결할 정도로 문제가 발생하나, 하고.
많은 삽질을 겪고서야 해결 방법을 발견하는 거겠지만 생각보다 겁먹을 것 없다고 느꼈다. git으로 협업할 때도 마찬가지. 문제가 생기면 해결하기만 하면 된다. 하다보면 어떻게든 답은 나온다!
3. 레이아웃 짜니까 재밌다
div 뭉치만 넣지 않고 최대한 시맨틱하게 작성하려고 노력했다. 그래서 섹션으로 큰 묶음을 넣고, 리스트 나열인 건 ul-li로 묶고, ... 그랬다. 비슷한 서비스를 제공하는 사이트에서 개발자도구로 살펴보며 많이 참조했다. 그런데 div 안에 ul을 넣는 이유나 div img를 넣는 이유가 궁금하다. 후자는 아마 img가 inline 요소라서 편의상 block인 div로 wrapping 해준 것 같은데.. 전자는 왜지?
ul, li를 생각보다 많이 쓰게 된다. 그래서 reset.css가 필요하다고 느꼈는데 처음 작성하기 전에 프론트 영역에서 이 얘기 했어도 좋았겠다. 다같이 프론트 -> 백으로 움직이다보니 영역별로 나눠서 소통할 기회가 좀 적은 것 같다. 결국 넷이서 떠들어야 하는 그런~
4. 코드 치는 나를 보며
디테일에 환장하는 편이라 지엽적인 것에 허덕이지 않도록 경계하는 중... 프론트는 정말 해도 해도 끝이 없다. 그래서 미련이 남고, 그 미련이 다음을 향하게 만드는 듯. 아예 프론트만 맡은 거면 진짜 미친듯이 디테일에 파고들 수 있는데 양쪽 다 하게 되니까 적당선을 찾게 되는 듯하다.
가만히 앉아서 하나만 주구장창 파는 걸 잘하다보니 한참 정신 놓고 코드의 세계에 머무는 것 같다. 예전에 영화 찍을 때도 몇 년 동안 영화 생각만 하고 살았는데.. 나는 내가 파고드는 성격이 아니라고 생각했는데 그 생각이 아닌 듯.
