본문 바로가기

우아한테크코스51

210714(수) - 페어 프로그래밍 1. 페어 프로그래밍 (프론트) 1. 페어 프로그래밍 (프론트) 전체적인 코드 스타일 맞춰 가기 처음에 프로젝트를 시작할 때, 페이지를 나누어 작업했던 탓에 변수명이나 컴포넌트 스타일과 같은 부분을 통일시켜야 하는 부분들이 남아있었다. 초기에 어느 정도 맞춰봐서 스타일이 크게 다른 것은 아니었지만, 세부적으로 조금 달랐다. 기능 상에는 전혀 문제없지만, 통일성이 조금 부족하다는 생각을 갖고 있었다. 개인적으로 코드가 잘못된(?) 방향으로 구현되어 있어도 통일성은 중요하다고 생각하는 주의라서 이 부분은 맞춰가고 싶었다. 통일성이 주는 가장 큰 장점은 코드를 예측할 수 있다는 점이다. 옳은 방향이든 잘못된 방향이든 이전 코드나 다음 코드 등을 예측해서 볼 수 있기 때문에 리팩터링에 유용하고, 처음 코드를 본.. 2021. 7. 14.
210713(화) - 추가 논의 1. 추가 논의 (프론트 + 백) 1. 추가 논의 (프론트 + 백) 후기 모음 페이지에서 각각의 탭에 접근할 때마다 데이터 받아올지 논의 각 탭을 클릭할 때마다 요청을 보내기로 했다. 다른 방법으로 페이지에 접근해서 데이터를 한 번에 가져온 후 글을 작성하거나 새로 고침 등으로 페이지가 새로 그려지는 경우에만 데이터를 가져올 수도 있는데, 사용자가 업데이트된 글을 바로 볼 수 있도록 하는 부분에 초점을 맞춰서 매 탭마다 새롭게 정보를 가져올 예정이다. 물론 잦은 클릭으로 인한 어뷰징도 막을 예정이다. 백엔드에서는 논의하기를 2가지 방식이 있는데, GET https://wnsah052.tistory.com/review?name=pfizer 와 같은 query parameter 방식과 GET https://.. 2021. 7. 13.
210712(월) - 페어 프로그래밍, 감정 회고 1. 페어 프로그래밍 (프론트) 2. 감정 회고 (프론트) 1. 페어 프로그래밍 (프론트) 다시 페어 프로그래밍으로 프로젝트를 시작하면서 페어와 나 모두 데모 데이(210719)까지 시간적 여유가 많지 않다고 느껴서 조급한 마음을 가지고 있었다. 이런 이유로 기본적인 디자인만 논의하고 바로 각자 컴포넌트를 제작하기로 결정했다. 그리고 어제 다시 만나서 서로가 만들었던 부분을 확인했다. 예상보다 컴포넌트를 제작하는 속도가 더뎠다. 기본적인 컴포넌트처럼 보여도 생각보다 신경 쓸 부분이 많았기 때문이다. 또한 각자가 생각하는 컴포넌트의 형태(props 등)가 달랐기 때문에, 페어가 만든 컴포넌트를 이용해서 내가 새로 컴포넌트를 만드는 상황에서 서로 매끄럽게 이어지지 못했다. 그래서 오늘 논의를 통해 페어 프로.. 2021. 7. 12.
210709(금) - 추가 논의 1. 추가 논의 (프론트) 1. 추가 논의 (프론트) 컴포넌트 타입 네이밍 관련 컴포넌트에 스타일 파일에서 타입이 필요한 경우, 객체 네이밍을 컴포넌트_props로 하기 -> ex) Label 컴포넌트가 sizeType을 받고 있으므로, 타입 관련 객체 네이밍은 LABEL_SIZE_TYPE 컴포넌트 prop 관련 (propTypes, defaultProps) prop으로 children이 온다면 맨 앞에 쓴다 propTypes에서 children은 항상 isRequired로 설정하고 맨 위에 쓴다. isRequired인 prop은 children 다음 줄부터 써준다 isRequired가 설정되지 않은 prop은 안정성을 높이기 위해서 default prop을 설정해야 한다는 eslint 규칙 추가 // .. 2021. 7. 9.