메인프로젝트 3Week

3주째 얼추 잡혀가는 틀....?

이번주 부터는 거의 회의를 안하고 각자 코딩하는 시간을 많이 가졌다. 중간중간 추가해야될 사항? API관련 문제로 소통하는것 외에는 각자 개발하는 시간을 많이 가졌습니다.

위에 화면은 keyframes 이용해서 글과 사진들이 슬라이드로 들어오는 애니메이션을 구성했고
scroll snap을 활용해서 하나의 섹션에서 다른섹션으로 넘어가는 효과를 만들었습니다.

헤더는 위에 GIF같이 심플하게 작성하였고

산책 상세페이지는 이런식으로 꾸몄습니다. hover를 했을때는 강아지를 산책에 몇마리 데려갈건지 정보를 띄우게끔 UI를 짰습니다.

현재는 백에서 서버 배포가 아직 진행되지 않아서 JSON서버에서 더미데이터들을 만들고 API get 요청을 보내서 데이터를 받아오고있는 상태입니다.

브랜치 관리....?

지금 어떠한 기능에 따라서 브랜치를 나누어 관리하고 있는데 git의 세계는 정말 복잡하다는것을 느꼈습니다.
지금 작업하고 있는 브랜치는 2개가 있는데 mainpage 브랜치와 WalkMateDetail 페이지에서 각각 기능에 맞는 작업들을 진행하고 있는 상태였는데 중간에 API DOCS가 완벽하게 구현되지 않는 상황이여서 중간에 산책 상세페이지에서 작업을 멈추고 메인페이지 브랜치에서 작업을 진행하고 싶었는데 브랜치를 바꾸기전 무조건 commit을 날려줘야하고 나중에 merge 할때도 conflict 문제가 발생하곤 했습니다. 그래서 구글링을 해본결과 보통 현업에서는 한가지 기능을 개발하는 branch를 만들고 그 기능을 완성시키고 다른작업을 진행한다고 들었고 이에대한 고민을 멘토님께 질문드렸습니다. 멘토님은 브랜치를 나눌때 FE BE 구역을 나누는게아니라 각 기능을 개발할때는 한브랜치 안에서 FE BE 둘다 작업을 해야된다고 하셨습니다. 애초에 이렇게 브랜치 전략을 나누는 것은 콘웨이의 법칙을 따라가고 있다고 했습니다. 개발 조직의 커뮤니케이션을 애초에 이걸로 설정했고 우린 이게 편하니 이걸로 진행하자~ 라는 식으로되서 지금 브랜치를 그렇게 판거고 문제도 발생한다고 했습니다. (콘웨이의 법칙 참고)

그래서 rebase, merge, revert, reset, cherry pick, checkout, switch, pull, pull —rebase, push, commit, squash merge, remote, … 등 자유자재로 다룰 줄 알아야하면 깃허븐 깃 등은 개발자의 기본소양이라고 하셨습니다. 현업에서도 알고리즘 코딩 기가막히게 짜는 사람도있는데 깃허브 깃을 잘 이용할 줄 몰라서 처음에 곤욕을 치른 사람도 있다고 해서 저는 이를 계기로 공부를 더 열심히 해야겠다고 느꼈습니다.

코드가 점점 길어진다..? 나누기 애매?