멤버십 1-2주차 회고

이번 멤버십 프로젝트는 2주동안 하나의 프로젝트를 진행해서, 프로젝트 회고 겸 작성했습니다.

회고를 가장한 TMI 주절주절 글입니다.

좋았던 점

아쉬웠던 점

앞으로는

이렇게 세가지 항목으로 나누어 작성했습니다.

사실 1주를 마무리하고 1주차 회고를 작성했는데,

급하게 쓰기두 했구 막상 공개하려니 부끄러워서 조금 더 다듬어서 함께 작성했습니다. >_ㅇ

잘된 점

1. Git
2. 왜?

시작하기에 앞서 이번 프로젝트는 개인 프로젝트였고,

이제껏 매번 페어 프로그래밍, 그룹 프로젝트를 진행하던 저에게 매우 생소한 작업이었습니다.

특히나 타이틀에 걸맞는 풀스택 개발이었기에 더더욱 생소했던 프로젝트였습니다.

하지만 결과적으로 정말 많은 것을 배울 수 있었고,

매일 새로운 이슈가 생성되어 처음 계획과 자꾸 멀어져서 이게 될까? 싶었는데,

어떻게든 마무리하고 배포까지 마칠 수 있었습니다 ^-^v

1. Git

개인적으로 가장 뿌듯한 것은 드디어 Git을 두려워하지 않게 되었다는 것입니다.

ssafy를 하면서, 그리고 챌린지를 하면서 push를 할 때마다 속으로 '제에발 충돌나지 말아라'라고 기도했습니다.

매번 git bash창에 뜨는 ERROR문구가 가장 무서웠고, 이제껏 작성했던 코드를 롤백해서 reset한다는 것이 두려웠습니다.

그래서 "branch는 더러워져도 상관없어. 내 코드만 살아있으면 돼!"라는 생각을 가지고 있었습니다.

하지만 이번 프로젝트를 통해 "code는 revert하면 되지. 대신 이력이 깔끔해야해"라는 생각으로 바뀌었습니다.

1일차를 마무리하고 2일차가 되는 날 rebase merge와 squash merge가 뭔지 모르고 그냥 merge하면 되겠지 하고 PR을 보냈습니다.

하지만 당연하게도 merge conflict가 생겼고,

이번 프로젝트 목표는 "1주차 안에 무조건 Git을 이해하고, 이제 Git에 시간 뺏기지 말자"로 바뀌었습니다.

다행히 하루 안에 conflict해결을 할 수 있었고, 다음과 같은 4가지를 배울 수 있었습니다.

1. merge (rebase merge, squash merge)

merge는 다 같은 merge라고 생각했습니다.
그래서 PR을 보냈을 때 conflict가 나지 않아 당연히 자동merge가 될 것이라 생각했으나
현재 진행 중인 프로젝트의 auto merge는 rebase merge를 사용해 conflict가 났습니다.

그래서 rebase가 뭔지, rebase merge와 squash merge의 차이점이 무엇인지 알 수 있었습니다.
이와 관련된 내용을 정리한 게시글 링크는 아래와 같습니다.

https://maeng2world.tistory.com/304?category=975386

2. 소스트리

merge를 해결하면서 branch간의 관계를 직접 눈으로 확인하기 위해 소스트리를 받았습니다.

(+ 커밋 메세지도 예쁘게 적어보고자 소스트리를 적용했습니다. 헿)

사실 vscode의 git branch extension도 있고, github desktop, 깃 크라켄 등 다양한 gui툴이 있지만,

학습 영상에서 소스트리를 쓰기도 했고, 주변에서도 소스트리를 많이 사용하기에 소스트리를 사용하게 되었습니다.
그리고 사실 gui툴들은 다 비슷비슷해서 ,, 고냥 암거나 써도 되자나여 ~!

3. git workflow

매 프로젝트마다 git flow 무조건이지!라는 생각으로 master-dev-features 형식으로 브랜치를 생성해서 진행했습니다.
이번에도 동일하게 master-dev-features 형식으로 진행했는데,
현재 프로젝트와는 맞지 않다는 것을 깨달았습니다.

기존에 진행했던 프로젝트는 5~6명의 팀원과 8주 동안 진행하기 때문에 git flow가 어울렸지만,
현재 진행하는 프로젝트는 매일 PR을 진행해야하고, 혼자 진행하고, 프로젝트의 규모가 크지 않기 때문에 git flow가 어울리지 않았습니다.

이번 경험을 통해 git flow가 무조건 좋은 것은 아니며, 프로젝트의 특성에 맞게 적용해야겠다고 깨달았습니다.

이와 관련해서는 이 글을 참고했습니다.

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

4. 서명(Verified)

github에서 merge를 진행하면 옆에 verified가 뜨고, 로컬에서 작업한 내역에는 verified가 뜨지 않아 찾아보게 되었습니다.

관련해서 정리한 게시글의 링크는 아래와 같습니다.

https://maeng2world.tistory.com/314?category=975386

5. git commit message

git에 관심을 가지면서 git commit message에 대해서도 찾아봤습니다.

기존에 git bash에서 진행할 때에는 헤더만 입력하여 type과 title만 담았다면,

소스트리를 사용한 이후로는 커밋 메세지에 본문도 담게되었습니다.

관련해서 정리한 게시글의 링크는 아래와 같습니다.

https://maeng2world.tistory.com/286?category=975386

아직 수정은 덜되었는데, type 중 update가 빠졌고,

저는 다음 프로젝트에서는 footer에 issue 번호와 바인딩할 예정입니다.

그리고 커밋 단위에 대해서도 다시 생각해봐야할 것 같아요.

이번에는 게임 중간저장 마냥 커밋을 찍었었는데,

issue를 조금 더 잘써서 해당 이슈별로 commit을 남기려고 합니다.

(중요: commit단위는 무조건 오류가 없어야함.)

아 참 요즘에는 깃모지도 많이 쓰더라구용?

이모티콘이 붙어서 덜 딱딱해보이고 직관적이어서 저도 다음에는 넣어볼까 합니다. (생각보다 많은 캠퍼분들이 사용했음)

관련 포스팅은 다음과 같습니다.

https://gitmoji.dev/, https://pilgwon.github.io/post/gitmoji

자랑: 결과적으로 2일차에 merge 관련 issue를 해결하고, 5일차에 다른 캠퍼의 git issue를 해결 했으니 뿌듯해하겠습니ㄷㅏ!!!!!!!!!
(((((((((((((((((((나))))))))))))))))))

2. 왜?

1주차에 프로젝트 초기 설정할 때 가장 고민했던 부분은 다음과 같습니다.

1. 어떤 DB를 사용할 것인가
2. 폴더 구조는 어떻게 나눌 것인가

였습니다.

예전 프로젝트 중 기획 단계가 귀찮고, 개발에 비해 덜 중요하다고 생각하여 무시하고 대충 했었는데

그 때 결국에는 프로젝트 중간에 기획 수정하고 의견 다시 맞추고 하는 과정에서 시간을 더 뺏기구 마음은 급하구 그래서 힘들었던 경험이 있습니다.

그 이후로 기획의 중요성은 깨달았지만, 그래도 무언가를 설정하는 데에 있어서 가장 큰 비중을 차지하는 것은 다른 기술 스택보다 이게 가장 내가 써본 기술이라서와 같은 이유였습니다.

하지만 OT에서도 그랬구 항상 마스터님들이 말하시는 "넘어져도 안전하게 넘어져봐라"라는 말씀이 너무 인상깊구 감동적이어서 ㅠ

이번 프로젝트에서는 내가 왜 이 기술 스택을 선택해야하는지에 있어서 현재 제가 가진 기술 스택의 비중을 조금 낮게 잡아서 생각해보았습니다. (나 < 프로젝트 관점으로)

그래서 DB는 최종적으로 NeDB를 사용하게 되었습니다. 이름만 들어도 생소하지만 생각보다 좋은 친구였습니다 ^-^v

그리고 프로젝트 구조에 있어서도 고민을 했는데요
처음에는 generator를 사용하지 않고 진행을 했는데, 결국에는 generator를 사용했습니다.
그 이유는

1. 초기 설정을 다 해주기 때문에 간편하다.
2. express를 사용하는 사람들이 주로 express-generator를 사용하기 때문에 다른 사람들이 내 코드를 봤을 때, 폴더 구조를 파악하기 용이하다. (가독성)
   라는 장점이 있기 때문입니다.

제 자신에게도 편리한 기능을 제공하지만, 코딩은 항상 함께하는 것이기 때문이지요 !

그래도 예전에 비해 다른 사람이 이게 좋다고 해서 그냥 쓰는게 아니라 왜 좋은지에 대해 알고 쓰는 고런 습관을 들일 수 있었던 것 같습니다 하하하

아쉬웠던 점

이제 제 자신을 객관적으로 바라보아야할 때입니다.

첫 주니까 .. (먼 산)

1. 중복 코드

프로젝트를 다 마치고 보니까 중복되는 코드가 많더라구요

심지어 같은 입력, 결과 값을 가진 같은 함수들이 다양한 파일에서 다른 이름으로 선언되는 magic. ..!

아 부끄럽지만 밝히는거예요 .. ㅎㅏ ..

여튼 이런 중복코드가 있으면 나중에 유지보수하기 힘들고,

같은 기능인데 달라질 수 있어서 일관성 유지하는 측면에서도 힘들고,

더 짧게 보면 개발 과정에 있어서도 issue가 발생했을 때 해결하는 데 더 많은 시간과 자원을 필요로하기 때문에 상당히 좋지 않은데요

마지막 날 호로로록 하다보니 중복코드가 너무 많아졌어요 ..

그 전까지는 100줄의 코드 중 30줄이 중복이라면 현재는 500줄 중 250줄이 중복이다 느낌..? (msg 투척)

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

ㅎㅏ..

근데 알고보니 util.js에 중복되는 코드들을 담아서 끌어다가 쓴다고 하더라구요 ..

그래서 다음 프로젝트에서는 이렇게 잘 관리해보려고 합니다 !!!!!!!!!!!!!!!!!!!!!! 아자

2. CSS 컨벤션

나름 컨벤션 지켜서 했는데, ..

혼돈 속 질서,,

요런 느낌이었는데...

하다보니 그냥 혼돈만 남더라구요

특히나 id값을 조금 남발한 것이 아닐까 싶습니다.

물론 프로젝트 규모가 크지 않아서 문제가 되지는 않았지만

조금만 더 컸다면 문제가 됐을거같아요.

그래서 id는 정말 필요한 값에 주고, 주로 class를 이용하자 ..! 라는 교훈을 얻었답니다.

그리고 class 명도 조금 더 가독성 좋게끔 하면 좋을 것 같다는 생각을 했어요 (자체 피드백)

아 참 그리고 어떤 분은 css 속성을 줄 때 display속성, color 속성 이런식으루 순서를 주더라구요 ?

나중에 속성이 길어지면 알아보기 힘드니까 중복으로 속성을 줄 수도 있으니 이런 방법도 좋을 것 같아요

근데 저는 다음 프로젝트에서는 css 속성도 조금 잘게 쪼개서 bootstrap처럼 쓸 수 있게 해볼까 합니다.

(원래 부트스트랩 애용자였음)

개인적으로 부트스트랩이 정말 편했거든요 ...

3. github issue, project, wiki

깃헙 이슈는 프로젝트 초기에 조금 생성했다가 github merge이슈 생긴 이후로 계획이 틀어지는 바람에 쳐다도 안봤는데요 ..^^..

다음 프로젝트에서는 계획을 더 꼼꼼히 짜서 issue를 제대로 설정해보려고 해요

• feature별 계획을 짠다 -> feature별 issue를 등록한다 -> issue별 commit을 한다
• 현재 진행 중인 issue를 project에서 관리한다 (칸반보드)
• wiki에 스프린트 진행사항을 업로드한다. -> 이와 관련해서 readme도 좀 잘 써보자 ㅠ

요정도가 되겠네요

issue는 예전에 jira사용했던 것처럼 하면 될거같구

project는 예전에 trello, jira사용했던 것처럼 하면 될거같아요!

가장 생소한 것은 wiki인데요

사실 그 동안 써보고 싶었는데 뭘 써야할지, 그리고 쓸만한 내용도 없어서 안썼는데,

다음 프로젝트에서 뭘 쓸지 고민을 하고 꾸며볼게요 ^-^~!

넘 기대됩니다

4. 매일 계획 피드백하기

3번과 이어지는 항목이기도 하는데요

이번에는 프로젝트를 하는 데 얼마나 시간이 소요될지 감이 안왔던 게 가장 큰 이유였던 거 같아요.

(DB 설정, API, 배포에 대해 얼마나 시간이 소요될지 감이 없었음)

그래서 크게 1주를 기준으로 1주 안에는 A, B기능을 다 하고 2주에 C, D를 하자와 같이 간결히 계획했었는데요

이렇게 하다보니 commit 기준도 애매하고 issue탭도 애매하고 뭔가 많이 애매해지더라구요?

뭔가 1주 단위가 하나의 뭉텅이가 된 느낌 ..?

그래서 그 뭉텅이를 조금 분해해보려고 해요

분해해서 더 구조적으로 만들어가지구 매일 계획 피드백하고 issue, project, wiki도 잘 써보려고 해용

아 그리구 계획에 학습할 시간도 추가하려고 해요.

예전에는 학습 시간은 무조건 개발 외 시간에 해야지 싶었는데

(tmi 최근에 스우파에 빠진 나 ..) 내로라하는 댄서들도 춤을 추면서 실수를 한다구 해용 안무를 까먹거나 고럴 때 그거를 자연스레 넘기는 것이 머찐 댄서라고 하더라구요

그 말을 보면서 개발자가 모르는 것(진짜 모르는 개념 혹은 issue와 같은 고런 것들)을 만나는 것도 당연하다는 생각이 들더라구요.

내가 20년 경력의 개발자가 되더라도 모르는 것은 항상 생기지 않을까 ..? 요런 생각

그럼 그 때마다 내가 이건 몰라서 어려워 힝힝 하는게 아니라 이거를 어떻게 잘 헤쳐나가냐가 개발자의 실력이 아닐까 싶더라구요

그래서 그런 부분을 보완할 수 있는 시간도 개발 시간 내에 넣어주려고 합니다.

말이 거창하지 그냥 이슈나 chore같은 거 해결하는 시간이죠

-> 한 마디로 너무 빡빡하게 안짜고 중간에 틈을 좀 주게따 입니다 ^-^

그리구 계획이 바뀌더라도 readme는 꾸준히 써야할 듯 합니다.

문서화의 중요성을 알면서도 귀찮아서 미루는 습관 고치기 ... ㅇ<-<

앞으로는

아쉬운 점을 쓰면서 앞으로 어떻게 해야할지까지 써버렸습니다

하지만 다시 리마인드 하자면

1. 중복 코드를 줄여보자
   • 이와 관련해서 코드를 좀 더 일관적으로 짜는 습관을 들여보겠습니다.
2. css 컨벤션을 지정하자
   • 부트스트랩과 같이 함 해보겠습니다.
3. github issue, project, wiki를 잘 써보자
4. README를 잘 써보자
5. 매일 계획 피드백

이 정도입니다.

첫 프로젝트라 그런가 생각보다 할 말이 많았네요

다음 주는 잘한점이 아쉬운점보다 많을 수 있도록 화이팅~~!

p.s
여기에 진짜 좋은 개발자들 많구 너무 많이 배우ㄹ 수 있어서 좋았습니다.
혹시나 1, 2주차에 저와 함께 하신 분들이 이 글을 본다면 만나서 너무 좋았구
피어세션 너무 즐거웠습니당 !!!!!!
많이 배울 수 있어서 좋았어용💜