개발
-
component와 hook 에 적용한 SOLID - [hook 편]
목차SOLID 원칙 - FrontEnd에 적용이 가능할까?내 코드 의존성의 원인해결 방법 - component 또는 hook이 알아야 하는 정보 줄이기 (S: 단일 책임 원칙)잘못 설계하는 과정 (실제 예시) - 어떤 컴포넌트를 만드는지 알려줄 거에요.hook이 담당하는 데이터를 최소한 작게 분리해서 생각해보기 - 의미 덜어내기hook 분리의 장점 (O: 개방 폐쇄 원칙)컴포넌트와 컴포넌트 hook과 hook 간 최소한의 소통 통로 (I: 인터페이스 분리 원칙)수정된 설계 과정 (실제 예시) - 어떤 컴포넌트를 만드는지 안 알려줄 거에요.추가된 요구사항 (실제 예시)잠깐 component이야기를 해보자. 렌더링에서 예상치 못하게 의존성이 문제가 되는 지점 - map 메서드 고찰 (I: 인터페이스 분리 원..
2024.07.21
-
prettier [파헤치기 편]
왜why 내 Prettier는 이상하게 동작하는 걸까? 빠르게 문제 해결 부분만 보기 문제 추측 가능한 원인 해결 npm 으로prettier 설치하지 않았는데, 강제 포맷팅이 된다 1. prettier extension 설치 2. default formatter로 prettier 지정 1. root 경로에 .vscode 폴더를 생성 2. 그 하위에 settings.json 파일 생성 3. 아래 내용을 입력 후 저장 { "prettier.requireConfig": true } npm으로 prettier을 설치했는데, 옵션을 아무것도 설정하지 않은 경우. {} 이 상태. 왜 프리티어가 적용되는 걸까? prettier의 기본 속성이 적용 .prettierrc파일에 포맷팅하고 싶은 속성과 옵션을 설정한다. h..
2023.11.27
-
팀원과 소통 비용 줄이기 (고찰)
경험적으로 얻은 교훈을 작성해보려고 합니다. 1. 상대방에게 요구하는 사항, 질문 의도를 먼저 말한다. 2. 개조식으로도 표현이 가능한지 확인 3. 문장이 너무 길어지지는 않는지 확인 4. 모호한 표현이 있는지 점검해서 보완한다. (조건 또는 수식어를 함께 작성) 5. 줄 간격이 좁은 경우 엔터로 단락을 구분한다. 6. 이미지 첨부 1. 줄글은 가독성이 떨어질 수 도 있다. 음? 설명을 길게 해야, 내가 고민한 부분들을 모두 전달할 수 있지 않을까? 그런데 글은, 읽는 상대방을 배려해야 한다. 너무 많은 정보가 한꺼번에 등장하면, 글을 이해하기 위해 다시 처음부터 읽어야 할지도 모른다. 글을 다 읽고, 다시 파악하기 위해 고민해본적이 있는지 생각해보자. 그래서 무엇을 말하는 거지? 여기서 요구하는 나의 ..
2024.03.28
-
PR 리뷰가 어렵다면, 해볼 수 있는 내용
웹접근성 https://accessibility.naver.com/accessibility div 대신 또는 Fragment 사용 SOLID 단일 책임 원칙 개방 폐쇄 원칙: 변경에 유용한가, 리스코프 치환 원칙 인터페이스 분리 원칙 의존성 역전 원칙 IoC DI 특히 설계는 너무 많은 것이 변경되지 않도록 처음부터 주의해서 설계해야 하는 것 같다. 하나가 변경된 경우 그것과 관련된 내용들이 같은 레벨, 또는 하위 레벨로 전파되어 수정 범위가 넓어지면 곤란한 상황이 생긴다. (API 명세가 바뀌었을 때, 함수의 매개번수 변경/추가 또는 컴포넌트 prop이 바뀐 경우도 있을 것 같다.) API 스펙이 바뀐 경우, 인터페이스가 있다면? 도메인 분류 네이밍과 관련된 부분일 수도 있는데, 주요 용어들은 통일하는..
2024.03.09
-
3차 프로젝트 회고
기획의 깊이에 대한 고민 (팀원들이 원하는 방향성, 기획 구성의 단단함. 가설을 세우고 검증하는건 어떨까) 와이어프레임을 Figma로 표현할지, 퍼블리싱까지 할 것인지 (Figma를 선택했던 근거) 와이어프레임을 일관된 디자인으로 정리하는 역할 담당 (제가 할게요) 팀원의 pain point를 눈치채고 도움주기 (마우스 클릭 소리를 듣고 해결, 드래그가 안된 부분 해결) PR 템플릿 양식을 전환하게 된 이유 (일관된 형식 유지. 불필요한 내용은 주석으로 전환) 테스트 코드의 필요성을 인식하게 된 계기 (글로는 아무리 정확하게 전달하려고 해도 조건에 따라 부정확할 수 있다) PR 리뷰의 장점. 리뷰를 작성하지 않아도 계속 PR을 followup 해야하는 이유 (좋은 코드, 진행 상황 파악, 고민 공유) 기..
2024.01.31
-
프로젝트 회고(2차 팀)
1. 담당 페이지 - 로그인 - 회원가입 - 채팅 컴포넌트 - 로딩 스피너 - Input - 채팅 item 컴포넌트 - 온라인 사용자 - 전체 사용자 1. 로그인/회원가입 라이브러리를 사용하지 않고 직접 구현 Input 컴포넌트 설계 (1) Input 컴포넌트의 기능 - 에러 메시지가 있는 경우 - 에러 메시지가 없는 경우 - 아이콘이 필요한 경우 고민: 구체적으로 UI 디자인을 설정하지 않아서 추가적인 UI 수정이 필요했고, 기능을 미리 정의하지 않아서 발생 ▶ 예: label과 placeholder글자 크기 차이 ▶ 예: 에러 메시지를 보여주는 시점 (1) 한글자씩 입력할 때마다 (2) 입력을 완료한 후 focus를 잃은 시점 (3) 폼 submit 클릭 후, 서버에 전송하기 전 ▶ 예: 에러 메시지..
2024.01.21
-
6개월, 프론트엔드 회고
내가 했던 것, 그리고 미리 생각해봤더라면 좋았을 내용 PR에 gif 이미지 첨부(PR을 더 잘 설명하기 위한 방법)커밋 생활화타 팀원과 교류하기팀에서의 나의 페르소나 돌아보기(예측 가능한 사람이 되도록)팀워크를 위해 팀규칙과 컨벤션 정하기스크럼 시간에 오늘의 할 일 목록 만들기(목표 달성으로 인한 성취감)팀원의 요청에 대한 나의 태도(긍정적인 방향으로 생각해보기)문서화. 변경사항 발생 시 반드시 알리기원격 근무시 갖춰야 할 태도(소통의 양방향성을 위해 카메라와 스피커를 켜야 하는 이유)슬랙 스레드를 읽고 반응 남겨야 하는 이유(읽은 사람 체크, 리마인드, 의견에 대한 반응 확인)팀 프로젝트 회고글 1. 첫 과제 PRGIF 이미지와 함께 업로드 간단한 과제였지만,● 직접 코드를 실행하지 않고도● 코드..
2024.03.17
-
FE 엔지니어의 Figma 사용법 (초급편)
Figma에 적용 할 기본 내용 폰트 크기 정하기(기본 16px? 14px? 12px?) 색상 규칙 만들기(컬러 팔레트 설정, 정해진 컬러를 사용하기) 레이아웃 설정(group, auto layout으로 css flex 구성 만들기) 컴포넌트화(React처럼 하나의 컴포넌트를 만들고, 컴포넌트의 원형 수정시 모든 복사된 내용에 반영되도록 합니다. 일일히 수정할 필요가 없기 때문에 매우 편합니다.) 디자인에 감각이 없는 나! Figma로 어떤 걸 해볼 수 있을까? 일관된 디자인을 구성하기 위한 최소한의 숙지 사항 디자인에 감각이 없는 나! Figma로 어떤 걸 해볼 수 있을까? 디자인을 담당 해주실 분이 없다면 '누군가'가 와이어프레임을 설계해야 할 때가 있습니다. 바로바로 지금! "디자인에 소질이 없습니..
2024.02.12