이번 프로젝트에서는 issue, milestone, wiki기능을 써봐야겠다는 다짐을 했습니다. 또한, 커밋 메세지를 작성하는데에 있어 header와 content, footer를 나누어 header에는 커밋의 종류와 제목을, content에는 어떤 내용이 변경되었고, 왜 이렇게 변경했는지와 참고한 링크를, footer에는 git issue 번호를 #number와 같은 형식으로 작성했습니다. (number에 issue번호를 달아주면 해당 이슈와 바인딩 되어 링크가 활성화됩니다.)
이와 같이 진행하면서 다음과 같은 고민이 생겼습니다.
issue 등록 기준은 어떻게 하지?
milestone은 며칠을 기준으로 생성하지?
wiki에는 어떤 내용을 넣어야하지?
커밋은 모든 이슈랑 바인딩 되어야할까?
이슈를 close한 후에 해당 이슈에 수정사항이 있을 경우 reopen을 하는 것이 나을까? 아니면 새로운 이슈를 생성하는 것이 나을까?
이에 대해서는 다음과 같이 결론을 내렸습니다.
issue를 작성할 때 기능 생성의 경우 컴포넌트 단위로 쪼개고, 오류의 경우 발생한 오류 기준, docs는 문서 하나 기준으로 작성해야겠다는 생각을 했습니다.
현재 프로젝트가 2주 프로젝트로 1주차, 2주차로 크게 나누기 때문에 1주차 milestone, 2주차 milestone으로 나누어 진행하는 것이 좋겠다는 생각을 했습니다. ssafy의 경우 7주 프로젝트였기 때문에 2주, 2주, 3주로 스프린트를 나누어 진행했기에 이 경험을 바탕으로 2주 프로젝트니까 1주차, 2주차로 나누어도 좋겠다는 생각을 했습니다.
프로젝트 관련해서 간략히 README에 작성하기 때문에 무엇을 작성할까 고민을 했는데, 다른 캠퍼분들을 참고하니 주로 다음과 같은 항목들을 작성한 것을 확인할 수 있었습니다. 1) API 명세 2) DB ERD 3) 프로젝트 구조 4) 매일 개발한 내용 등 .. 이를 보며 저 또한 API 명세와 DB ERD, 프로젝트 구조를 담아야겠다는 생각을 했습니다. 매일 개발한 내용은 노션에 작성하고 있어 이를 간략히만 작성해서 wiki에 담아놔도 좋겠다는 생각을 했습니다.
footer영역에 이슈번호를 바인딩 하기로 마음 먹으니 footer가 존재하지 않는 커밋들이 생기는 것도 이상한 거 같고, 그렇다고 의미없는 이슈(예를 들면 readme 갱신)를 만드는 것도 issue의 취지와 맞지 않다고 생각했습니다. 그래서 이와 관련해서 코드를 리뷰해주시는 멘토님께 리뷰 질문으로 남겨놨는데요 다음과 같은 답변을 받을 수 있었습니다.
이와 관련해서도 리뷰 질문으로 남겨놨는데요 다음과 같은 답변을 받을 수 있었습니다. 이를 기반으로 issue는 주로 의사결정 혹은 토론 용도로 사용하는 것이구나를 유추할 수 있었습니다.
2. 프로젝트 관련
백엔드의 경우 express, 프론트엔드의 경우 vanilla JS를 사용하는데요 이번에 webpack boilerplate를 만들어 사용하게 되었습니다. 처음에는 boilerplate 코드가 뭐지 ..? 싶었는데요. 공부하다 보니 기존에 "템플릿 코드"라고 불렀던 것이었습니다. 예를 들면 html파일을 작성할 때 기본으로 사용하는 다음과 같은 코드도 boilerplate코드라고 할 수 있습니다.
webpack boilerplate를 작성하는 데에 있어 시간 소요를 많이 했습니다. 처음에는 boilerplate니까 범용성이 높아야한다는 생각에 프로젝트 구조를 생성하기 전에 검색해가며 boilerplate를 먼저 작성했습니다. 그렇게 webpack을 작성하고 프로젝트에 이식했다가 프로젝트 구조를 고민하지 않았다는 것을 깨달았습니다. 껄껄껄
그래서 다음과 같은 고민을 했습니다. 프로젝트 구조는 어떻게 설계하지?
처음에는 front, back 폴더를 나눠서 해야겠다 싶었습니다. 근데 나눠서 진행할 경우 CORS 문제를 해결해야하고, 쿠키 정보 공유가 불가능하다.는 단점이 있습니다. 결국 폴더 구조를 예쁘게 할 수 있는 것 말고는 장점이 보이지 않았습니다. 그리고 webpack을 사용하기 때문에 이런 고민할 필요가 없었다 ..!
하지만 그 당시에는 정말 많은 고민을 했습니다 ^-^..!
지금은 3줄에 끝나는 내용이지만 webpack을 만드는 기간 내내 많은 고민을 했습니다. 지금 보니 좀 어이없네요
그리고 프로젝트 구조를 설계하는 것에 있어 front내부는 어떻게 나누지에 대해서도 고민을 하게 됩니다. 이에 대한 내용은 이제 아래 아쉬웠던 점에서 이어 이야기하겠습니다.
3. 코드 관련
코드 작성에 있어 고민했던 사항은 아래와 같습니다.
svg파일은 svg태그 그대로 코드에 삽입해야하나 아니면 img태그를 사용해 src속성에 svg태그의 위치를 삽입해야하나
store를 사용해 상태 관리를 하는데 props를 이용해 정보를 넘겨주면 다른 사람(내 코드를 보는 사람)이 코드를 이해하는 것이 어렵지는 않을까?
1번의 경우
svg태그 그대로 코드에 삽입할 경우
장점: style을 수정할 수 있다.
단점: 코드가 길어져서 가독성을 해친다.
svg파일을 img태그 내 src속성에 파일 위치를 삽입할 경우
장점: 코드가 간결해진다.
단점: style을 수정할 수 없다. 라는 장단점이 있었기에 고민을 많이했습니다.
2번의 경우 store을 이용해 상태 관리를 하는데 props를 이용해서 데이터를 넘겨주면 어떤 데이터는 store에서부터 오고, 어떤 데이터는 props에서 오기 때문에 다른 사람이 제 코드를 읽고 데이터 흐름을 이해하는 데에 어려움을 겪을 것이라고 생각했습니다. 그래서 store에서만 관리를 해야겠다 생각했는데, 다른 곳에서 사용되지 않고 그냥 단순히 한 방향으로, 한 번만 쓰이는 데이터의 경우에는 props를 이용해서 넘겨줘도 되지 않을까?라는 고민을 했습니다.
이에 대해서도 코드 리뷰시 질문으로 남겨놨는데요, 아래와 같은 답변을 받을 수 있었습니다.
새로 알게된 사실
index.js파일은 import할 경우 파일 이름을 제외하고 import를 해도 해당 파일에 접근하게 됩니다. 이 부분은 피어세션을 함께 진행한 다른 캠퍼분이 공유해준 내용입니다. 프로젝트 폴더 구조를 고민할 때 다른 사람들의 구조를 많이 찾아봤는데요, 그 때마다 폴더 내부에 index.js가 많았는데 왜 많은지 알게 되었습니다.
위와 같은 폴더 상황에서 app.js에서 calendar내부의 index.js를 import해서 사용할 때 `import { fn } from './calendar'`로만 해도 index.js를 import할 수 있습니다.
변수 선언부와 로직은 분리되는 게 코드 가독성에 좋습니다. 이 부분은 당연하지만 코드를 작성할 때에는 놓치기 쉬운 부분이라 이 곳에 기록합니다.
이전까지는 밤샘코딩 or 밤샘프로젝트를 즐겨했는데요, 이제는 ... .. 영양제도 꾸준히 챙겨먹고 수면 시간도 지키고, 해야할 것들을 정해놓고 하려고 합니다. (사실 mbti 파워 P인데.. J처럼 변하겠다는 뭐 그런 말 ..)
부스트캠프에서는 "지속가능한 개발자"라는 말을 사용하는데요, 지속 가능한 개발자가 되기 위해서 이렇게 밤샘 코딩을 즐겨하면 안되겠다는 것을 느꼈습니다. 또한 지속 가능한 개발자가 되기 위해서는 공부도 게을리 하지 않고... 모르는 내용이 생기면 절대 미루지 말고 해결하고 기록하자 .. (최근에 이 부분에 있어 현민님이 기술 잔반이라는 단어를 쓰셨는데 정말 찰떡이더라구요! 하
!) 즉, 기술 잔반을 남기지 말자..! 미래의 나를 위해서 ..
!
성장하고 있나봅니다.
사실 이번 프로젝트 하면서 제 자신이 "물음표 살인마"처럼 느껴졌습니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아니 진짜 "이게 맞나.."를 입에 달고 산 나 ..
이와 관련해서 준영님이랑 이야기하다가 "예전에는 큰 의미없이 했던 프로젝트 구조에 대해 고민하고, 이제는 폴더명도 신경쓰이고 뭐가 답인지 모르겠다" 라고 했는데요
예전에는 그냥 구현이 목표였다면 이제는 구현이 아닌 깔끔한 코드, 구조를 위해 노력하기 때문에 이와 같은 고민이 생기는 것 이라고 말해주더라구요 진짜 감동받았습니다.இ௰இ
생각해보면 작년 이맘 때 swea에서 와
! 인풋은 이렇게 받는거구나
! 와~! 프린트는 이렇게 하는 거구나 했는데 말이죠 ..!
그리고 최근에 CS 시험을 봤는데요 저는 사실 한 문제도 못풀까봐 걱정 많이했는데, 문제가 풀리더라구요 ! 신기했습니다. 꾸준히 하면 되나봐요
이제는 추석 연휴처럼 공부에만 집중할 시간이 없으니까 이제 더더욱 시간 관리를 잘해서 꾸준히 공부를 해놔야겠다 라는 생각이 들었습니다.
Prettier, ESLint를 적용했습니다. 사실 제 기술 잔반 중 하나였는데요 .. 드디어 적용했습니다. 아 너무 편해요 왜 이런걸 진작 할 생각을 못했을까요 진짜 최고예요 기술 잔반 처리한 기념으로 좋았던 점에 추가했습니다^-^
아쉬웠던 점
일단 제 욕심을 나열해보자면
이제 webpack도 사용할 거고, 지난 프로젝트와는 달리 중복코드를 없애고 싶었습니다.
깔끔한 코드와 한 눈에 보이는 구조! 이었습니다. 욕심이라고 적은 이유는 위 목표 때문에 키보드 위에 손을 올릴 수 없었기 때문이죠.
지난 프로젝트에서 스파게티처럼 꼬여있던게 정말정말정말 아쉬웠기 때문에 같은 실수를 반복하고 싶지 않았고, 때문에 설계를 꼼꼼히 하면 같은 실수를 범하지 않겠지라는 생각으로 ..
하지만 이 목표가 결국 제가 목표를 달성하지 못하게 만든 범인이었습니다.
어느 정도로 꼼꼼한 설계에 대한 강박이 있었냐면 4일차까지 reset CSS와 기본 CSS 설정 외에는 존재하지 않았습니다.
비유를 하자면 바닷가에 놀러가서 모래성을 쌓으려고 하는데, 모래에 이물질이 많이 섞여있어 울퉁불퉁해지니까 모래를 솎아내고 솎아내어 고운 모래만 사용해서 모래성을 쌓겠다 느낌 ..? 적당히 돌멩이를 솎아내는 것은 필요하지만, 굳이 체까지 사용할 필요가 없잖아요? 그런 느낌이었습니다.
적당히 만들다가 돌멩이가 튀어나오면 그 돌멩이만 빼내고 다른 모래로 채우면 되는건데 말이죠~~
이와 관련해서 좋았던 점에도 적었지만, 그래도 아쉬운 부분이 더 큰거 같아요
멘토님도 이와 같이 코멘트 남겨주셨구요 ..!
앞으로는
일단 폴더 구조 대략적으로 잡아놓고 안되면 app.js에 다 담아놓고 시작해보자. (프로젝트 구조 설계에 1일 이상 소요 금지.)
생활 루틴 잡기, 영양제 챙겨먹기: 새벽 코딩을 줄이자 ..
모르는 내용은 절대 미루지 말고 해결하고 기록하기
내일부터 다시 3번째 프로젝트 시작인데, 시작하기에 앞서 2번째 프로젝트를 보내주기 위해 이렇게 글을 써봤습니다^-^
