요즘 멘티들이 가장 궁금한 건 현업에서도 진짜 이렇게 협업할까? 지금 내가 하는 게 맞나?! 입니다.
물론 회사마다 다르겠지만 멘토님들의 현업 경험을 녹여주시면 멘티들의 시야를 넓히는데 큰 도움이 되리라 생각합니다! :)
[미해결] git flow 전략
git flow 전략을 따르고 있습니다. 예를 들어 develop으로부터 feat/30 브랜치를 따서 컴포넌트를 개발하고 있는데 develop에 변경사항이 있어서 pull을 받아와야할 때 현재 작업 중인 브랜치로 받아오는지 궁금합니다! (push, pull 등이 어떤 프로세스를 거치는 지)
동영
feature 브랜치에서 develop를 pull해야 하는 경우는 크게 두 가지 경우가 아닐까 싶습니다.
PR을 보내려고 했더니 충돌이 발생하는 경우
feature를 만들고 나서 오랫동안 작업하는 경우
사실 2번처럼 feature 브랜치의 수명이 길어지면 길어질수록 1의 가능성이 증가할 수밖에 없습니다. 만약 2번 경우라면 브랜치를 생성-머지 주기를 짧게 이어갈 수 있도록 브랜치의 작업 범위를 줄이는 편이 좋고, 어찌됐든 결과적으로 충돌이 발생했다면 develop의 변경 사항을 feature로 가져와서 충돌을 해결할 수밖에 없습니다. 그 밖에 git log를 깔끔하게 유지하기 위해 충돌이 발생하지 않았더라도 PR을 보내기 전 rebase랑 squash를 진행하도록 협업 규칙을 정하기도 합니다.
[미해결] router 템플릿 썼을 때 다른 페이지에도 적용되는 문제 해결법
예시 화면
위와 같이 작성하면 MypageTemplate이 /createPost에도 적용되어
다음과 같이 수정하여 사용 중입니다.
이처럼 사용하는 방법이 맞는 것인지, 다른 해결 방법은 어떤것 이 있는지 궁금합니다.
요한
Route에는 말 그대로 경로만을 위한 코드만 작성합니다. 공통의 템플릿을 사용하고 싶을 경우에는 각각의 루트페이지에서 LayoutTemplate을 각각 import해서 사용합니다.
[미해결] 현업에서의 업무 강도
현재 2주 프로젝트가 굉장히 빡빡하다고 느끼는데, 현업에서도 이 프로젝트와 같이 업무 강도가 강한가요? 물론 회사에 따라 다르겠지만 멘토님들의 현업 스토리가 궁금합니다!
선협
당연한 이야기지만 회사마다 다릅니다. 이번 프로젝트의 경우 자유 형식이라 팀마다 느끼는 정도가 다르겠지만 제가 생각한 기준(단순 CRUD만 구현, 웹 소켓 X, 디자인/UX 고려 X)에선 적당하다고 생각하고 있습니다.
[미해결] 실무 프로젝트 프로세스는 어떤가요?
현재 저희 팀은 기능 연결 없이 컴포넌트의 껍데기(?)를 먼저 구현한 뒤, 라우팅을 연결하고 api를 연결하는 순서로 작업하고 있습니다. 실무에서는 어떤 프로세스로 진행되는지 궁금합니다.
선협
회사마다, 팀마다 다르겠지만 보통 다음과 같이 일을 진행합니다.
무엇을 만들지 의논
작업 할 일에 대한 이슈 생성
이슈 assign
작업
코드 리뷰
머지
코드 구현 방법에 대해서라면 사람마다 많이 다르기 때문에 어떻게 한다라고 말씀드리기는 어렵습니다. 단, 크게보면 Top-Down으로 구현하는 것과 Bottom-Up으로 구현하는 경우로 나뉩니다. 말씀하신 방법은 Top-Down에 가까워 보이네요.
[미해결] SVG 파일을 다루는 방법
svg 파일을 어떻게 다루시는 지 궁금합니다. svg를 img, div 태그로 가져오면 스타일을 조정하는 것이 어렵다고 알고 있어서 svg 태그로 직접 가져와서 사용했습니다. 하지만 이때의 문제점은 svg가 path를 따라 영역을 차지하는 것이 아닌 path의 최대 너비, 최대 높이만큼의 직사각형 모양의 영역을 차지하고 있었습니다. 이를 해결하기 위해 div에 clip-path로 svg를 전달하는 방식을 사용했습니다.
선협
svg를 React 혹은 Vue 컴포넌트로 만들어서 사용합니다. 이때 svg는 규칙을 정해 고정된 viewBox를 사용하고 컴포넌트에서 속성을 통해 크기를 조절하도록 만듭니다.
[미해결] 개발 속도가 다른 팀원과의 협업
현재 저희 팀은 각자의 개발속도에 차이가 있습니다. 업무의 분배는 동일한 편이라고 생각합니다. 각자 베이스 컴포넌트, 훅과 페이지를 분배하여 프로젝트를 진행하고 있습니다.
다만 문제는 개발 속도가 상대적으로 느린 팀원이 개발하고 있는 컴포넌트(A)를 개발 속도가 빠른 팀원의 다른 컴포넌트(B)에서 필요로 할 때입니다.
저희는 개발 속도가 빠른 팀원이 일단 개발이 완료되지 않은 컴포넌트(A) 대신 임의로 데모로 작성하여 기능(B)을 개발하는 방식을 선택했습니다.
시간이 조금 흘러 A가 완성된 경우, 데모 컴포넌트로 개발이 되고 있던 B 컴포넌트도 이슈를 생성하여 수정을 해야 하는지 궁금합니다.
현업에서는 베이스 컴포넌트, 훅, 페이지에 대한 분배를 각각 하여 개발을 하는지, 아니라면 어떻게 개발 업무를 분배하여 협업을 하고 있는지 궁금합니다.
동영
여러 사람이 함께 개발하면서 개발 속도에 차이가 발생하는 건 당연한 일이 아닐까 싶습니다. 그런데 업무의 분배가 동일하다는 부분에서 살짝 오류가 있는 게 아닌가 하는 생각이 드는데요. 분배가 동일하다는 근거가 단순히 산술적인 이슈의 할당량을 기준으로 말씀하신 거라면 잘못된 방향이라는 생각이 듭니다. 개발 속도의 차이라는 게 절대적인 실력의 차이 때문일 수도 있지만, 접근 방식이나 사람 자체의 성향에 따라 다르기도 하며, 업무 성숙도에 따른 차이일 수도 있을 겁니다. 각 팀원의 상황과 수준을 고려하고 그에 맞는 난이도, 분량을 기준으로 분담하되 A가 작업을 시작하기 전에 B의 작업물을 필요로 한다면 A가 B가 작업을 빠르게 끝낼 수 있게 돕는 방법도 하나의 유효한 방법이 될 수 있습니다.
선협
업무를 나누고 분배하는 것을 연습해야합니다. 물론 이런 것이 쉬운 일은 아닙니다. 한 번 다음과 같이 정해보세요.
스크럼 시간에 무엇을 할지 정합니다.
할 일을 정했다면 일을 어떻게 쪼갤지 정합니다.
쪼개진 일은 각자가 assign 합니다.
자신이 맡은 일이 어느정도 걸릴지 미리 정한 후 진행합니다. 이때 걸리는 시간 단위를 스토리 포인트라고 합니다. 1시간을 1 스토리 포인트라 정하고 하루의 총 작업 시간을 8 스토리 포인트라고 정해봅시다.
하루 업무를 마치고 스토리 포인트가 얼마나 정확했는지 따져봅니다.
스토리 포인트 측정 결과를 보고 다음 스크럼 때는 조금 더 정교할 수 있도록 조정합니다.
...반복
위와 같이 대략적인 업무 시간을 측정할 수 있습니다. 따라서 만약 업무를 잘 쪼갠다면 각 팀원에게 효율적으로 업무를 분배할 수 있게 됩니다. 쪼개는 방법은 정해지진 않았습니다. 팀마다 많이 다르겠죠. 이 부분은 회의를 통해 정해나가면 됩니다.
[해결] 실무에서는 어떻게 머지하나요?
현재 3인 팀이 머지 규칙을 전체 팀원 리뷰 승인 하에 진행하고자 하는데 다음과 같이 진행했을 경우 제 개인적인 소견으로는 아래와 같은 이슈가 발생할 것이라고 생각합니다.
- 일정이 늦어질 수 있음
- 의견 충돌 문제
- 기간이 짧고, 소규모인 현 프로젝트에서는 리뷰어를 여러명 설정함이 중요치 않아 보임
멘토님들의 현업 이야기가 궁금합니다! 👀
오프 멘토
리뷰를 세명이상 반드시해야한다는 룰이 있으면 의미있는 리뷰 보다는 바빠서 LGTM 범벅이 될 것 같다는 예측을 조심스럽게 해봅니다.. 그래도 한명 이상은 리뷰를 받는 것이 좋아보이고, 인원 수보다는 코드리뷰 목적에 맞춰서, 적어도 책임을 나눠가진다는 의미에서 잘 이뤄지도록 해야 할 것 같습니다. 그 과정에서 의견충돌이나 일정이 늦어지는건 그 또한 프로젝트의 묘미가 아닐까..라고 생각합니다. (너무 많은 시간에 리뷰를 사용해서 문제가 된다면 하루에 일정 시간(1~2시간)을 정해서 “우리는 오후 2시부터 코드리뷰다. 오후 2시 이후에 올라온 코드는 내일 리뷰다.” 이런식으로 해도 괜찮을 것 같습니다. 급한거라면 또 융통성있게 할거라..)
김요한 멘토
저희는 실무에서 전원 approve해야만 머지 할 수 있습니다.리뷰를 남긴다라기보다 확인 및 승인 과정이라고 생각합니다
마크 멘토
저희는 리드 개발자분이 approve 한 후 머지 할 수 있도록 되어있으나 그 전에 자유롭게 팀원이 리뷰가 가능하도록 되어있습니다 (슬랙 연동으로 올리자마자 알림이 울립니다)
달리 멘토
저도 3명팀이면 전체 인원이 `approved `merge 프로세스로 가도 문제 없을 것 같은데 팀별 스타일에 맞게 유동적으로 가도 좋을 것 같아요.
코드리뷰 한 분이 더 보는 점으로 일정에 큰 차이가 없을 것 같아요 -> 유지보수 생산성면에서는 오히려 이득?
의견충돌은 오히려 실무나 팀이 스타일을 맞추는 경험을 많이 해볼수록 좋지 않을까 싶습니다 (개인 프로젝트로 나머지 경험은 할 수 있으니까요)
로토
프로젝트의 상태에 따라 조금 다른데, 빠르게 개발해야하는 모드인 경우 1명만 approve하고 머지를 하기도 합니다. 이 경우에도 변경사항이 크거나 다른 사람들의 작업에 영향이 많이 가는 경우 all approve를 하는 등 유기적으로 합니다.
운영 모드인 경우에는 가급적 all approve를 받은 후 머지 하도록 하고 있습니다.
가끔 핫픽스로 나가야하는 경우만 예외를 둡니다.
김지은 멘토
저희는 인원이 적기 때문에, 수석 개발자님이 백엔드, 프론트 코드를 직접 리뷰하며 수석 개발자님께서 approve 하면 머지됩니다.
컴포넌트 만드는 PR일경우에는 디자이너분들도 reviewer에 멘션 걸어서 리뷰 요청합니다.
저희는 PR단위 배포를 하기 때문에, 디자이너분들도 PR단위 배포된 것을 브라우저에서 확인 후 이상이 없으면 approve 합니다.
모든것은 일정에 차질이 없이 진행되며, 일정이 촉박 하다면 일단 merge한 후에 배포하고나서 그때 코드리뷰를 진행합니다.
[해결] Vue로 프로젝트를 진행하며 궁금한 점
Q1. 웹페이지 내의 data 일관성을 위해서 가능한 모든 data를 vuex를 이용해서 공유하는 방식을 사용하고 있는데 이런 방식이 잘못된 방식인지 궁금합니다! (예외) 입력값이 필요한 경우에만 data를 가지고 있습니다.
요한
프로젝트 성격마다 다르긴 하지만 제 경우에는 백엔드에서 가져오는 데이터들은 대부분 vuex store에서 가져와서 사용하고 있습니다. 다만 (이건 상황마다 달라서) 수정할 필요가 없는 자식 컴포넌트에게 prop을 넘겨줘서 사용하는 경우도 있습니다.
영웅
모든 데이터를 Vuex에서 관리할 때 나중에 규모가 커지면 너무 복잡해 집니다.
되도록 중앙 집중이 필요한 데이터만 Vuex를 이용하시길 권장해요.
달리
vuex가 나온 이유에서 맞게 필요한데만 사용하는 것이 좋을 것 같아요.
가능하면 전체 data에 저장하는 부분을 줄여야 분리가 잘되고, 유지보수에 용이할것입니다.
Q2. 새로고침시 vuex store가 다 날아가는데 이거는 로컬스토리지를 사용하고 있는데 다른 방식을 사용할수 있을까요?
요한
날아가도 상관없는 데이터다고 판단된다면 굳이 모든 내용을 로컬 스토리지에 저장하는 일을 하지 않습니다.
다만 auth 토큰의 경우에는 401 오류 등이 생길 수 있기 때문에 다시 백엔드에서 토큰을 retrieve하는 로직을 axios interceptor에서 처리합니다.
달리
쿠키나 url에 관련정보가 있다면(queryString) 새로고침해도 계속 같은 data를 불러올 수 있을 것 같아요.
Q3. vue 협업시 충돌 방지를 위해서 App.vue , routes/index.js 와 같은 진입 파일은 건드리지않고 개인별로 따로 파일을 추가해서 하는방식으로 진행하고 있습니다. 현업에서도 이런 방식으로 충돌을 방지하는지 궁금합니다. 혹시 더 나은 충돌 방지 방법이 있을까요??
요한
App.vue나 routes등은 최대한 한 사람 (저희 팀의 경우에는 리드 개발자)가 수정하며, 팀원에게는 페이지단위나 컴포넌트 단위로 일을 분배해서 최대한 충돌을 피합니다
[해결] 토큰을 사용한 사용자 인증
Q1. 상태 관리 라이브러리를 통해 토큰을 저장해서 페이지를 이동할 때마다 유효한지 검증하는 방식이 맞는지? 실무에서는 이렇게 사용하는지 궁금합니다.
영웅
저는 로컬스토리지 + 쿠키를 활용하고 있습니다.
쿠키는 동일 도메인에서 이동할 수 있어서 활용하고 그 외는 로컬스토리지를 사용합니다.
유효성 검증 API를 만들어서(백엔드) 해당 토큰 정보가 유효한지 모든 페이지에서 판단합니다.
어떻게 처리하느냐에 따라 달라지겠지만, 기본적으로 상태 관리 라이브러리에서 토큰을 관리하는 방법도 많이 사용합니다. 대신 토큰 정보는 통제가 가능한 최소한의 범위에서만 쓰시길 바라요.
로토
SPA인 경우 처음 initialize 단계에서 1회만 하고 있습니다. 이후 서버에 API를 찌를 때마다 해당 토큰을 헤더나 파라메터 등에 실어서 보내고, 서버에선 API 요청을 받을 때마다 토큰을 체크하여 자연스럽게 유효성을 계속해서 검증하는 방식이죠.
이후 토큰이 만료되었다는 에러가 서버에서 내려오면 리프레시 토큰을 이용해 토큰 연장을 하는 처리를 하고 있습니다. 우선 필요한 구현이 몇가지가 있는데
서버에서 해야하는 구현
서버에서는 인증된 토큰을 헤더나 파라메터 등으로 항상 받도록 합니다.
서버에서는 API 호출이 들어오면 위의 토큰을 먼저 검증합니다.
검증에 성공하면 원래 API 동작을 하고, 검증에 실패하면 401 에러를 던집니다.
클라이언트에서 해야하는 구현
API 요청시 인증된 토큰을 헤더나 파라메터 등으로 서버와 약속된 방식으로 던집니다.
API 요청을 처리하는 곳에서, 만약 응답이 401이 떨어졌을 경우의 처리를 합니다.
인증 토큰과 리프레시 토큰을 같이 발급 받아서 이때 리프레시 토큰을 이용해 새 인증 토큰을 발급 받고 성공 시 해당 토큰을 local storage에 저장한 뒤 하려던 API 다시 요청
리프레시 토큰으로 새 토큰 발급 받기 실패 시 로그아웃 처리
보안을 생각하면 매 페이지 이동시마다 체크해도 상관은 없지만, Server Side Rendering의 경우 페이지 진입하기 전에 체크가 끝나서 괜찮은데 Client Side Rendering의 경우 렌더링 이후에 인증을 ajax로 체크해야하는데 이때 불필요하게 화면이 블락되거나 하는 등 사용성이 좋지 않을 수 있습니다. 그래서 위에 적은 것처럼 초기 단계에서만 하던지 하는 타협점이 필요합니다.
Q2. 토큰 유효성 과정을 코드로 예시를 보고 싶습니다. (저같은 경우는 컴포넌트 자체에 토큰 유효성을 체크했는데 비슷한 예시를 본 적이 없어서 옳게하고 있는 것인지 궁금합니다.)
로토
react.js 기준이긴 한데요.
function App() {
const [isInitialized, setInitialized] = useState(false)
const checkToken = async () => {
// token 검증함
if (isValidToken) {
setInitialized(true)
} else if {
history.push('/login')
}
}
useEffect(() => {
checkToken()
})
if (!isInitialized) {
return null
}
return (
// 하위 컴포넌트 렌더링
)
}
위의 로직을 별도의 Context로 뽑아서 쓰기도 합니다.
유효성을 마친 이후에 렌더링이 시작되기 때문에 하위 컴포넌트에서는 유효성 체크를 신경 쓸 필요가 없습니다.
[해결] 팀플이 처음인 우리... 어떻게 일을 분배하나요?
처음으로 프로젝트를 진행하며 팀장을 담당하게 되었습니다. 팀원들에게 어떻게 일을 배치할지, 현재는 하고 싶은 것을 서로 나누었는데 이 방법이 맞을지도 고민입니다... 😢 어떻게 해야 효율적으로 일을 분배할 수 있을까요? 팀플 시 일을 분배하는 기준이 있을까요?
로토
일을 시작하기 전에 먼저 플래닝을 가볍게 해보시는 것도 좋으실 것 같습니다. 먼저 해야할 일들을 리스트업 한 다음
각 일의 우선순위를 논의해서 측정하고
각 일들에 대해 working day를 각자 추정해봐서 평균을 매겨둔 뒤,
working day 기준으로 1주 혹은 2주 단위로 할 수 있는 일과 우선순위가 높은 일들을 뽑아서 분배해보시는 건 어떨까 싶네요.
김지은 멘토
로토님과 의견이 비슷합니다.
일을 시작하기전에 기획이 어느정도 마무리 후 디자인이 어느정도 나왔다면 플래닝 을 합니다.