Skip to content

10월 30일 회의

Jump to bottom
lee0jae330 edited this page Nov 1, 2024 · 5 revisions

숙제

  • FE / BE 컨벤션 알아오기
  • 기술 스택 알아오기
  • 라이브러리 찾아오기(블록리)
  • 프로젝트명 1개 생각해오기
  • 노랑 초록 메인 컬러로 디자인 가이드 → 타이포 / 그레이 베리에이션

할 일

  • 프로젝트명 정하기 → github repo 이름 변경하기

  • 사용할 기술 스택 정하기

  • 사용할 라이브러리 정하기

  • FE / BE 컨벤션 정하기

  • figma 사용법 익히기

  • 디자인 레퍼런스 찾기

  • 디자인 진행하기

  • DAN 2024 3시

  • 장원영 권나연

    프로젝트명

    Block

    HTML

    CSS

    • 프리블 (프리뷰 + 블록)

      블록 단위로 미리보기 제공

    • 프린이

      코린이

      엔트리 = entry = 프로그래밍 학습 입문

    • CSSBLOCK

      씨블락

    관련 서비스

    디자인가이드

    https://github.com/shadcn-ui/ui?tab=readme-ov-file

    https://pyjun01.github.io/v/shadcn-ui/

    • 컴포넌트 단위
    • 라이브러리가 아니라 컬렉션 형태

    https://brunch.co.kr/@designjay/2

    tailwind 사용시: https://github.com/saadeghi/daisyui

    블록코딩: 파랑 배경에 노란 포인트

    지금보니 색조합 비슷한듯..?

    • 스크래치

    • 엔트리

    다크모드 적용 예정이라면 참고해야할듯

    → 코드작성창이 있으므로 필수 아닐까

    https://color.adobe.com/ko/search?q=web

    기술스택

    FE

    언어: JS or TS

    프레임워크: React or Next

    • 컴포넌트 단위 개발이 블록 단위 구성에 적합할듯

    • Nextjs의 장점

      • SSR → 서비스 출시할 경우 이점

      • 파일 기반 라우팅 → 페이지가 많이 나뉘지 않는 편

      • API 라우팅

      • Vercel 최적화

        리액트 프로젝트에서도 가능하긴 함

      하지만 오버스펙일 수 있음

    상태관리: zustand

    • 러닝커브가 낮다고 들음

    스타일: tailwindcss

    생산성 갑,,

    https://www.creative-tim.com/twcomponents/cheatsheet/

    드래그앤드롭

    Blockly 기본 제공으로 기억

    토스트바: https://react-hot-toast.com/

    BE

    DB: Firebase 또는 Supabase

    기능 Firebase Supabase
    데이터베이스 Firestore (NoSQL) PostgreSQL (SQL)
    실시간 데이터 실시간 동기화 (Firestore/Realtime DB) PostgreSQL 기반 실시간 기능
    인증 다양한 인증 옵션 기본적인 이메일, 소셜 인증 지원
    확장 기능 Functions, ML Kit, 호스팅, 애널리틱스 등 기본적인 API 지원, 서버리스 함수 제한적
    유연성 Firebase의 폐쇄적 환경 오픈소스 기반, 직접 호스팅 및 커스터마이징 가능
    비용 트래픽이 많아질수록 증가 비교적 저렴하지만 대규모 트래픽 시 증가
    커뮤니티와 문서 매우 풍부한 문서와 커뮤니티 Firebase보다 적은 커뮤니티와 자료

    • 개인적인 생각

      • RESTful api를 제작하는데에 있어 생산성과 스웨거 문서를 자동으로 생성해주는 것, 초기설정의 부담감이 적다는 것이 굉장히 큰 메리트로 다가오긴 함.
      • 하지만, 러닝커브와 1차적으로는 우리 프로젝트에 사용자 인증이 크게 중요하지 않다는 점, 많은 api가 필요하진 않다는 점을 고려하면 express가 더 낫지 않나 라는 생각도 든다

    • sequelize

      • 모델 생성이 편리함
      • 원시 sql 쿼리 사용 가능
      • 개인적인 후기: typescript로 쓰기 더럽게 어렵다. 오류가 아주..

    • typeORM

      • typescript 수용
      • 데코레이터 활용으로 엔터티와 관계 정의 가능

      https://npmtrends.com/sequelize-vs-typeorm

      • 이제 엇비슷한 것 보니 타입스크립트 사용이 늘어날수록 typeorm으로 바뀌어가는 추세가 아닐까? js를 쓰면 확실히 sequelize가 편할 것 같은데

        image.png

    DB

    • MongoDB
      • ncp cloud DB for MongoDB 사용
      • 프로젝트 상태 정보를 프로퍼티가 많은 json형태로 저장해야하다 보니 NoSQL 형식이 적합하다고 생각.
    • SQLite
      • 동시편집이 가능해지면 사용
      • 무겁게 MySQL을 사용할 필요는 없다고 생각
    • Redis
      • 동시편집이 가능해지면 사용

    배포 및 클라우드 서비스

    • nginx
      • ssl/tls 지원 → https 설정 가능
      • 단일 서버에서 여러 어플을 같이 올릴 수 있음 (프론트/백 서버 분리 필요x)
    • docker
      • 컨테이너 가상환경
        • 호스트 서버에 영향 x
    • github actions
    • ncp server

    프로젝트 이름

    https://chatgpt.com/share/67211136-73d0-8008-af7e-721ffb446812

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

    웹블럭탕 아니면 태그사시미 아니면 태그돌잔치ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

    Web31-webBlockTangtang

    Web31-sashimiTag

    Web31-FistBirthdayPartyOfTagBaby

FE / BE 컨벤션

https://react-icons.github.io/react-icons/

![image.png](https://prod-files-secure.s3.us-west-2.amazonaws.com/53787a23-833d-4223-97ad-45d76b4d684c/e7835e9e-146d-438e-a84b-3f66e645cd9d/image.png)

image.png

숙제

  • FE / BE 컨벤션 알아오기
  • 기술 스택 알아오기
  • 라이브러리 찾아오기(블록리)
  • 프로젝트명 1개 생각해오기
  • 노랑 초록 메인 컬러로 디자인 가이드 → 타이포 / 그레이 베리에이션

할 일

  • 프로젝트명 정하기 → github repo 이름 변경하기

  • 사용할 기술 스택 정하기

  • 사용할 라이브러리 정하기

  • FE / BE 컨벤션 정하기

  • figma 사용법 익히기

  • 디자인 레퍼런스 찾기

  • 디자인 진행하기

  • DAN 2024 3시

  • 장원영 권나연

    프로젝트명

    Block

    HTML

    CSS

    • 프리블 (프리뷰 + 블록)

      블록 단위로 미리보기 제공

    • 프린이

      코린이

      엔트리 = entry = 프로그래밍 학습 입문

    • CSSBLOCK

      씨블락

    관련 서비스

    디자인가이드

    https://github.com/shadcn-ui/ui?tab=readme-ov-file

    https://pyjun01.github.io/v/shadcn-ui/

    • 컴포넌트 단위
    • 라이브러리가 아니라 컬렉션 형태

    https://brunch.co.kr/@designjay/2

    tailwind 사용시: https://github.com/saadeghi/daisyui

    블록코딩: 파랑 배경에 노란 포인트

    지금보니 색조합 비슷한듯..?

    • 스크래치

      image.png

    • 엔트리

      image.png

    다크모드 적용 예정이라면 참고해야할듯

    → 코드작성창이 있으므로 필수 아닐까

    https://color.adobe.com/ko/search?q=web

    https://color.adobe.com/ko/search?q=web

    기술스택

    FE

    언어: JS or TS

    프레임워크: React or Next

    • 컴포넌트 단위 개발이 블록 단위 구성에 적합할듯

    • Nextjs의 장점

      • SSR → 서비스 출시할 경우 이점

      • 파일 기반 라우팅 → 페이지가 많이 나뉘지 않는 편

      • API 라우팅

      • Vercel 최적화

        리액트 프로젝트에서도 가능하긴 함

      하지만 오버스펙일 수 있음

    상태관리: zustand

    • 러닝커브가 낮다고 들음

    스타일: tailwindcss

    생산성 갑,,

    https://www.creative-tim.com/twcomponents/cheatsheet/

    드래그앤드롭

    Blockly 기본 제공으로 기억

    토스트바: https://react-hot-toast.com/

    BE

    DB: Firebase 또는 Supabase

    기능 Firebase Supabase
    데이터베이스 Firestore (NoSQL) PostgreSQL (SQL)
    실시간 데이터 실시간 동기화 (Firestore/Realtime DB) PostgreSQL 기반 실시간 기능
    인증 다양한 인증 옵션 기본적인 이메일, 소셜 인증 지원
    확장 기능 Functions, ML Kit, 호스팅, 애널리틱스 등 기본적인 API 지원, 서버리스 함수 제한적
    유연성 Firebase의 폐쇄적 환경 오픈소스 기반, 직접 호스팅 및 커스터마이징 가능
    비용 트래픽이 많아질수록 증가 비교적 저렴하지만 대규모 트래픽 시 증가
    커뮤니티와 문서 매우 풍부한 문서와 커뮤니티 Firebase보다 적은 커뮤니티와 자료

    컨벤션

    airbnb 한글: https://github.com/tipjs/javascript-style-guide

    공통

    • 모노레포?

    • 할일 주석처리

      // TODO:

    FE

    TS?

    https://techblog.woowahan.com/9804/

    https://fe-developers.kakaoent.com/2021/211012-typescript-tip/

    모듈시스템: ESM

    https://tech.kakao.com/posts/605

    https://toss.tech/article/commonjs-esm-exports-field

    • 각 모듈(폴더)별로 index.js 만들어서 한번에 export/import하기
    • export는 객체에서 직접?

    네이밍

    길어지더라도 최대한 자세히

    - Bad case : handleClick
- Good case : handleUserLogin

    레포지토리명

    • 케밥 케이스
    • ex) directory-name

    폴더/ 파일/ 컴포넌트

    • 파스칼케이스
    • 함수 정의한 경우 카멜케이스?
    • ex) ComponentName

    클래스/ 타입명

    • 파스칼케이스
    • ex) ClassName, TypeName

    함수/ 변수명

    • 카멜케이스
    • 배열의 이름은 복수형으로 작성
    • 함수는 동사 + 𝝰로 작성
    • 반환값이 boolean이라면 is + 𝝰 로 작성
    • ex) functionName, variableName chats

    상수명

    • 대문자, 스네이크 케이스
    • ex) VARIABLE_NAME

    이벤트 핸들러

    • 핸들러를 전달하는 프로퍼티의 이름: 접두사 on

    • 핸들러 함수: 접두사 handle

      function Form({ onSubmit }) {
  const handleSubmit = () => onSubmit();
  return (<form>
    <button type="submit" onClick={handleSubmit}></button>
  </form>);
}

    BE

    https://github.com/felixge/node-style-guide

    그외

    • 서기
    • 문서타임 (목요일?)

    참고

    [https://github.com/boostcampwm2023/web16-B1G1/wiki/코딩-컨벤션](https://github.com/boostcampwm2023/web16-B1G1/wiki/%EC%BD%94%EB%94%A9-%EC%BB%A8%EB%B2%A4%EC%85%98)

    [https://github.com/boostcampwm-2022/web22-BooCrum/wiki/코딩-컨벤션](https://github.com/boostcampwm-2022/web22-BooCrum/wiki/%EC%BD%94%EB%94%A9-%EC%BB%A8%EB%B2%A4%EC%85%98)

    [https://github.com/boostcampwm2023/web01-GitChallenge/wiki/컨벤션](https://github.com/boostcampwm2023/web01-GitChallenge/wiki/%EC%BB%A8%EB%B2%A4%EC%85%98)

  • Faker 이영재

    프론드 엔드

    기술 스택

    React or Next.js

    → Next.js는 SSR을 시도해보고 싶으면 도입 웬만하면 React 쓰는게 좋을 것 같습니다.

    번들러

    • Vite

    언어

    • TypeScript

    패키지 매니저

    • npm

    폴더 구조

    라이브러리

    컨벤션

    • ESLint, Prettier 사용

      • [AirBnb Style Guide](https://github.com/apple77y/javascript/tree/master/react)를 사용

        • eslint 제약이 너무 심하면 조금씩 완화하는 방식으로 설정하면 좋을 것 같습니다.

      • Prettier 설정

        [Prettier + ESLint + Airbnb Style Guide | TechWell](https://techwell.wooritech.com/docs/tools/prettier/prettier-eslint-airbnb/)

        module.exports = {
  printWidth: 80, // 한 줄 최대 문자 수
  tabWidth: 2, // 들여쓰기 시, 탭 너비
  useTabs: false, // 스페이스 대신 탭 사용
  semi: true, // 문장 끝 세미콜론 사용
  singleQuote: true, // 작은 따옴표 사용
  trailingComma: 'all', // 꼬리 콤마 사용
  bracketSpacing: true, // 중괄호 내에 공백 사용
  arrowParens: 'always', // 화살표 함수 단일 인자여도, 괄호 유지
  proseWrap: 'never', // 마크다운 포매팅 제외
  endOfLine: 'auto', // 개행문자 유지 (혼합일 경우, 첫 줄 개행문자로 통일)
};

        여기서 printWidth가 너무 짧은거 같으면 100 정도로 설정해도 좋을 것 같습니다.

    • 문장 종료

      • 반드시 세미콜론 사용 !

    • 변수 및 함수는 카멜 케이스 사용

      배열
//list 접미사로 끝나게 명명하기
const [~]list = []

정규표현식
//r로 시작
const rName = /!@#/;

이벤트 핸들러
//on으로 시작
const onClick = () => console.log("클릭");

반환값이 boolean 타입이면
//is, can 접두사 붙이기
const isLoading = true;
const canClick = false;

    • 블록 구문

      • 한 줄짜리 블록이어도 {}를 생략 x → 무조건 줄바꿈 하기
      지양
if(isLoading) return "loading";

지향
if(isLoading) {
	return "loading";
}

    • 함수

      • this 바인딩을 꼭 사용해야 하는 경우가 아니면 화살표 함수를 사용하기

        const fnName () => {}

const arr = [1,2,3,4];
arr.map((x) => x);

    • 주석

      • 해야할 부분이 남았거나 추후에 개선할 부분이 있으면 TODO 를 사용한다

        //TODO

      • 함수에 대한 설명이 필요하면 JSdoc을 사용한다

        /*
 * @description ~
 * @params  ~
 * return ~
*/

    • 클래스는 파스칼 표기법 사용 → User

    • 상수는 대문자 스네이크 표기법 사용 → const SNAKE_CASE = 10;

    • Type Interface 파스칼 표기법

      • Type을 사용할 것인지 interface를 사용할 것인지 정하면 좋을 것 같습니다.

    • 폴더 네이밍

      • 카멜 케이스를 기본으로

      • 컴포넌트 폴더일 경우에만 파스칼 케이스 사용

        camelCase

PascalCase

    • 파일 네이밍

      • 컴포넌트일 경우만 .jsx (.tsx) 확장자를 사용 → 그 외에는 .js (.ts)
      • customHook을 사용하는 경우
        • use + 훅 이름
      • 전역 상태의 경우
        • 상태 이름 + store

    백엔드

    기술 스택

    Express

    장점

    • Express는 아무래도 학습 스프린트 기간동안 해본 경험이 있으니 금방 금방 코드 작성이 가능할 것 같습니다.

    단점

    • MVC 패턴과 같이 직접 아키텍처를 선정하고 폴더구조도 직접 만들어야 한다는 점이 생산성을 저하시킬 것 같습니다.

    Nest

    • Nest는 Express 기반 프레임워크

    장점

    • NestJS CLI 를 통해 파일을 구조화된 파일을 만들 수 있음
      • 모듈 생성
        • nest generate module <module-name>
      • 컨트롤러 생성
        • nest generate controller <controller-name>
      • 서비스 생성
        • nest generate service <service-name>
    • 아키텍처가 정해져있음
      • 아키텍처를 정하고 폴더구조를 구성하는데 시간이 소요되지 않음
    • 타입스크립트 지원

    단점

    • 학습하는데 시간이 소요됨
      • 모듈 시스템으로 동작하여 프로젝트를 모듈 단위로 분리하여 구조화하는 방식을 익혀야 함
      • 의존성 주입 (DI)의 개념을 알고 이해하는 것이 중요함
        • 이 부분이 러닝 커브를 키울 것 같습니다.
      • 데코레이터를 통해 API 엔드포인트, 의존성 관리
        • @Controller, @Get, @Post, @Injectable 등등

    러닝커브 때문에 Express가 끌리긴 한데 NestJs를 익히고 나면 되게 손쉽게 백엔드 코드를 작성할 수 있을 것 같아서 저는 반반입니다..

    여러분들의 의견이 궁금합니다 !

    DB : MySql, MongoDB

    ORM: Sequelize, TypeORM

    컨벤션

    폴더 이름

    • MVC 패턴 적용 시 파일 역할 별로 네이밍
      • controllers, routes, models, services, middlewares, utils, config 등등

    파일 이름

    • 각 파일을 기능별로 명확하게 네이밍
      • authMiddleware.ts
      • userController.ts

    코딩 스타일

    • 변수, 함수 이름은 카멜 케이스 사용
      • camelCase
    • const, let을 사용해 변수 선언, 가능하면 const로 선언하기

    코드 문서화

    • JSdoc을 활용하여 설명이 필요한 함수에 명세 작성하기
    • api의 경우, swagger 활용하기

    프로젝트명

    • 블록빌더
    • 차곡차곡
      • 블록을 쌓는다는 의미에서..
    • 블록에서 웹사이트까지

    디자인 레퍼런스

    [Stratis UI - Task Grid](https://dribbble.com/shots/20660211-Stratis-UI-Task-Grid)

    학습 컨텐츠를 이런식으로 보여주면 어떨까? 싶어서 가져왔습니다

    [Dashboard](https://dribbble.com/shots/14238788-Dashboard)

    [Dashboard and Shared Workspace](https://dribbble.com/shots/16070586-Dashboard-and-Shared-Workspace)

    워크스페이스 대쉬보드 관련 레퍼런스입니다

  • 윈터 이유진

    FE 컨벤션

    • 컴포넌트 폴더, 파일명은 파스칼 케이스로 작성한다.

    • 컴포넌트 폴더는 다음과 같은 구조를 가진다. 컴포넌트를 사용할 때 index.tsx를 import 한다.

      Button
ㄴ index.tsx // 컴포넌트
ㄴ Button.styled.ts // 스타일링
ㄴ button.test.ts // 테스트
ㄴ Button.stories.ts // 스토리북

    • 나머지 폴더명은 카멜 케이스로 작성한다.

    • 함수명은 동사뒤에 명사가 오도록 조합하고 카멜 케이스로 작성한다.

    • 컴포넌트 props 타입은 <컴포넌트명>Props 형태로 선언한다.

      export interface ButtonProps {}

    • model 타입은 파스칼 케이스로 작성한다.

      export interface User {}

    • 이벤트 핸들러 props에는 on 접두사를 붙이고, 값으로 넘길 때에는 handle 접두사를 붙인다.

      function Form({ onSubmit }) {
  const handleSubmit = () => onSubmit();
  return (<form>
    <button type="submit" onClick={handleSubmit}></button>
  </form>);
}

    • Early Return 패턴을 사용한다.

      if (!password) {
	alert("비밀번호를 입력해주세요");
  return;
}

    라이브러리

    👉

    라이브러리 선택

    • 모든 도구와 라이브러리를 자유롭게 사용할 수 있음
    • 모든 선택에는 조사과정이 있어야 하며, 비교대상도 있어야 함.
    • 이 과정을 최소 라이브러리별로 1Day정도로 진행하고 결과를 위키등 문서화 시킨다.
    • 프로젝트 후반에는 라이브러리 사용에 대한 회고를 문서로 남긴다.

    CSS 라이브러리

    동적으로 바꿀 스타일이 있기는 하지만, 일관된 디자인을 빠르게 만들어 내려면 tailwind CSS가 좋다고 생각한다.

    분류 라이브러리명 장점 단점
    CSS-in-JS Styled-Components, Emotion - 컴포넌트와 스타일이 결합되어 코드 유지 관리가 편리
    • 동적 스타일링을 쉽게 할 수 있다 | - 런타임 오버헤드 존재
    • 속도가 다른 라이브러리에 비해 느림 | | Atomic CSS | Tailwind CSS | - 빠르고 반복 가능한 스타일링
    • 디자인 일관성을 유지하기 쉬움
    • 파일 크기 절감 및 컴파일 최적화
    • 클래스명을 짓는 시간을 줄일 수 있음 | - 가독성 저하
    • 복잡한 컴포넌트에서 클래스가 많아질 수 있음 | | Zero-runtime CSS-in-JS | Vanilla Extract | - 타입 안정성 보장
    • 컴포넌트와 스타일이 결합되어 코드 유지 관리가 편리
    • Zero-runtime으로 성능 우수 | - 동적 스타일링 어려움 |

    https://velog.io/@lovelys0731/CSS%EC%9D%98-%EC%97%AD%EC%82%AC-%ED%86%BA%EC%95%84%EB%B3%B4%EA%B8%B0

    https://www.devdive.co.kr/react/css-library-comparison

    https://www.dhiwise.com/post/styled-components-vs-tailwind-css-finding-the-perfect-style-for-your-react-project

    https://github.com/jsjoeio/styled-components-vs-emotion

    상태관리 라이브러리

    전역 상태로 관리할만 게 떠오르는 건 사용자 정보 정도. 복잡한 상태 관리는 안 할 것 같아서 러닝커브가 적은 Zustand가 좋다고 생각한다.

    라이브러리 특징 장점 단점
    Redux 전역 상태 관리 - 디버깅 도구 지원
    • 중앙 집중화 | - 초기 설정 복잡 | | Zustand | 가벼운 상태 관리 | - 간편한 사용법
    • 러닝 커브 적음 | - 복잡한 상태 관리 부족
    • 중복 상태 관리 어려움 |

    블록코딩 라이브러리

    • Blockly

    • Socket.IO

      https://github.com/socketio/socket.io

      동시편집이 아니더라도 블록 조작을 서버에 저장하려면 WebSocket이나 WebRTC를 이용한 실시간 통신이 좋을 것 같다. 사용자가 블록을 움직일 때마다 서버에 HTTP 요청을 보내는 방식은 과도한 요청을 발생시킬 것 같다. 그리고 기술적으로도 실시간 통신을 공부할 수 있으니 좋다고 생각!

      동시편집할 때는 P2P를 한다면 webRTC를 사용하는 게 좋다고 생각. 그래서 동시편집이 없을 때는 web socket으로 1차 구현한 후 동시편집을 넣을 때 webRTC를 사용하고 p2p 방식으로 변경해도 좋을 듯.

    번들러

    라이브러리 특징 장점 단점
    Webpack 모듈 번들링 도구, 다양한 플러그인 지원 강력한 커스터마이징, 큰 생태계 설정이 복잡하고 어려울 수 있음
    Vite 개발 서버와 빌드 도구 통합 빠른 핫 모듈 교체(HMR), 간단한 설정 상대적으로 새로운 도구라 자료 부족

    테스트

    라이브러리 특징 장점 단점
    Jest JavaScript 테스팅 프레임워크 간편한 설정, 스냅샷 테스트 지원 대규모 프로젝트에서 설정이 복잡할 수 있음
    React Testing Library React 컴포넌트 테스트 도구 사용자 관점에서 테스트 작성 가능 컴포넌트 내 로직 테스트 어려움

    StoryBook

    • UI 개발 환경: 독립적인 환경에서 컴포넌트를 개발하고 테스트할 수 있음
    • 문서화: 컴포넌트의 다양한 상태를 웹페이지로 만들어주기 때문에 문서화하기 편리
    • 플러그인 지원: 다양한 애드온을 통해 기능을 확장 가능

    기술 스택

    • typescript
    • react
    • vite
    • styled-components or tailwindcss
    • zustand
    • storybook
    • jest
    • socket.io

    생각한 프로젝트명

    boo + try(부트리): boo덕이와 블록코딩을 try한다.

    직관적이고 부르기 편하고 사람들 머리 속에 기억이 잘 남는 이름을 좋아합니다.

    Foundation

    피그마 [foundation 페이지](https://www.figma.com/design/nv2pP4yUPGkdoaie2SHsfR/%EB%94%94%EC%9E%90%EC%9D%B8%EB%B3%B4%EB%93%9C?node-id=64-92)에 만들어 두었습니다.

    image.png

    참고

    • 캐릭터 채도 올려야 한다.
    • 디자인 완료 후 필요한 부덕이 variation은 주말에 마무리한다.
    • 노랑, 초록, 파랑은 만들면서 조금씩 수정할 수도 있다. (컬러 변수 만들어서 할 것이라 수정 걱정은 불필요)
    • 로고는 프로젝트명에 맞게 수정한다. logotype이 확정되면 벡터화한다.
    • typography와 color는 token만 만들었다.
    • icon은 suit 폰트와 어울리는 subbase foundation에서 가져왔다. 만약 없는 아이콘이 있을 경우 통일성을 위해 모든 아이콘을 material icon으로 변경한다. (아니면 아이콘 통일된 곳 아무곳이나 좋음)
    • spacing은 따로 가이드를 만들지 않았지만 4의 배수로 지정한다.

    Figma

    같이 디자인하기 위해서 함께 학습하면 좋은 것

    • 오브젝트 이동 / 복사 / 사이즈 조절 단축키 ****

    • layout grid 보는 법

    • auto layout(hue, fill) 사용법

      shift + a

    • 모든 간격은 4의 배수에 맞춘다. 아이콘은 12 배수 (안되면 2의 배수에 맞춘다. 홀수는 사망이다. ex. 6px, 10px, 382px…) line height 때문에 4의 배수로 spacing 할 수 없다면 오브젝트의 크기를 4의 배수로 맞춘다.
    • spacing은 종류 별로 동일한 크기를 사용한다.
    • 텍스트 박스의 크기를 직접 조절하지 않는다.
    • auto layout이 아니면 오브젝트를 절대 마우스로만 이동시키지 않는다.
    • ctrl + c 하고 까먹지 않는다.
    • 실수로 디자인을 건드리는 것 같으면 무조건 뒤로가기한다.

  • 차은우 최경일

    • 컨벤션

      • 참고링크: [FE 코딩 컨벤션](https://velog.io/@bleuuue/Front-End-%EC%BD%94%EB%94%A9-%EC%BB%A8%EB%B2%A4%EC%85%98)

      • 기본적인 ESLint, Prettier 규칙

      • 들여쓰기 2문자

      • 작은 따옴표 ‘ ‘

      • Arrow function

      • 한줄 길이는 100자

      • 주석

        • 한 줄은 //
        • 두 줄 이상은 /* */
        • 주석 문구와 // 사이에 공백 1칸 ex) //할일 → X, // 할일 → O

      • 네이밍 컨벤션

        • 폴더/파일/함수/변수/컴포넌트
          • 폴더명 kebab-case
          • 파일명
            • 컴포넌트 파일 PascalCase
            • 타입 및 통신 파일 camelCase or kebab-case
          • 함수명 camelCase
          • 컴포넌트명 PascalCase
        • 가급적이면 약어 대신 직관적인 네이밍. 명사+동사 순서
        • 상수는 스네이크 케이스 + _
        • props로 전달하는 핸들러 함수는 on 으로 시작
        • 컴포넌트 내부에서 직접 정의하는 이벤트 핸들러 함수는 handle 로 시작
        • Boolean 타입 변수는 is 접두사
        • 배열은 접미사 Arr ex) todoArr
        • 객체는 접미사 Obj ex) userObj
        • Interface 선언은 접두사 I
        • type 선언은 접두사 T

      • 간단한 if문은 삼항 연산자

      • if문 사용시 항상 중괄호 { }

        // Bad
if (condition) return;

// Good
if (condition) {
  return;
}

      • 공백

        • 콤마 다음에 값이 오면 무조건 공백이 있어야 한다.

        • 키워드, 연산자와 다른 코드 사이에 공백 필수

          // Good
var value;
if (typeof str === 'string') {
  value = (a + b);
}

// Bad
var value;
if(typeof str==='string') {
  value=(a+b);
}

    • 기술 스택

      • React + TypeScript + Vite
      • CSS: styled-component or tailwind css
      • 상태관리: Zustand + Tanstack-Query

    • 라이브러리

    • 프로젝트 명 후보들

      • EasyHTML
      • LayoutLab
      • Drag&Learn
      • BlockBuilder
      • Drag&Code

  • 카리나 홍현지

    컨벤션

    FE 컨벤션

    • airbnb 컨벤션

    • toast.ui 컨벤션

    • 함수사용 - 화살표함수 vs 일반함수

      • react 16.8 이후로 일반함수, 화살표함수의 사용의 차이점은 없다시피 무의미함. 단순 개인취향으로 갈라짐
      • 개취는 화살표함수 (보기가 더 깔끔함, 특히 컴포넌트 내부에서 쓸 때)

    • 폴더구조

      • api
        • 도메인 별 클래스로 관리
        • tanstack-query 사용시 api 별로 hooks-queries 폴더에 useHook 파일 분리
      • 폴더명 - 카멜케이스 / 파일명 - 파스칼케이스
      ├ api/
├ assets/
│   ├ fonts/
│   ├ imgs/
│   └ icons/
├ components/
│   ├ common/
│   │   ├ Input.tsx
│   │   └ Button.tsx
│   ├ home/
│   │   └ home에서만 사용되는 common보다는 복잡한 컴포넌트들..
│   └ login/
├ layouts/
├ hooks/
│   └ queries/
├ utils/
├ lib/
├ routes/
├ pages/
├ style/
│   ├ global.css
│   └ color.ts
└ types/

    • type 선언에 관련하여

      • type? interface?
      • 타입 선언 시 타입명은 반드시 뒤에 Type을 붙인다.

    BE 컨벤션

    기술스택

    FE

    프로젝트 빌드

    • cra
      • 빌딩 시간이 김 → 모든 모듈을 한 번에 변환하기 때문에
      • vite에 비해 HMR 시간이 김
        • HMR: 실행하는 동안 코드 변경사항에 대해 실시간으로 모듈을 업데이트하고 적용하는 기능
        • cra는 모든 코드를 번들로 묶은 후 다시 빌드해야 해서, 변경 범위가 커질수록 성능 저하가 발생
    • vite

      • 빌딩 시간이 짧음 → 모듈을 동적으로 변환하기 때문에

      • rollup을 사용 → tree-shaking에 적합

        • +) 트리셰이킹에 관해서.. 이건 좀 컨벤션 혹은 폴더 및 파일 구조를 관통하는 내용인데, 7~8주차 스프린트에서 인덱스패턴..?을 사용하는 경우를 종종 봤는데

          인덱스 패턴이 경로를 간소화 시키는 것과 요소들을 모듈화 시키는 데 적절하다고 생각하는데, 예전 피어세션에서 한 피어분이 아무래도 컴포넌트들을 한꺼번에 가져와 사용하다보니 리액트에선 트리셰이킹이 안되는 문제가 발생할 수도 있다. 그럼 성능적인 측면에서 보았을 때 괜찮은 방식인가 고민이 된다 라고 하셨음.

          ⇒ 이것에 대한 답변으로, nextjs 12버전 보면 인덱스패턴을 잘 쓰는 것에 대해 알 수 있을 듯 이라는 대답을 듣기도 함.

      • 개발 과정에서 빠른 HMR을 제공

    패키지매니저

    • npm

    • yarn

    • yarn berry

      • 프로젝트를 가볍게 하려면 yarn berry가 좋다고 했는데.. 제한적인 패키지가 있어 설치가 좀 까다롭다라는 말을 들었음
      • blockly 설치에 무리가 없을지..

    • [pnpm](https://pnpm.io/)

      📖

      pnpm의 경우에는 프로젝트별로 node_modules에 매번 패키지를 설치했던 것과는 달리 global 저장소에 패키지를 한 번만 저장함으로써 저장 공간을 절약할 수 있다는 아주 큰 장점을 가지고 있다.

      즉, pnpm을 사용한다면 똑같은 라이브러리를 중복해서 설치할 필요가 없다는 의미다.

      https://velog.io/@sebinn/%ED%8C%A8%ED%82%A4%EC%A7%80-%EB%A7%A4%EB%8B%88%EC%A0%80-%EB%B9%84%EA%B5%90-npm-yarn-pnpm

      • 아무래도 글로벌 저장소에 저장하다보니 개발환경에서는 거부감이 좀 들수 있다고 생각
      • 배포를 pnpm으로 하면 좋을 듯..? 아닌가? 대규모 회사에서는 배포 규모도 다르고, 그만큼 서버의 활용방식이 다를테니 좋을 것 같긴 한데, 작은 단위의 프로젝트에서는 다른 패키지와 비교해 큰 장점이 있을지는 모르겠음.
        • 멘토님께 여쭤봐도 좋을 듯

    스타일

    • tailwind

      • 7~8주차 멘토님께 tailwind가 선호되고 있는 이유를 여쭤보았을 때 아래와 같이 답변해주심
      📖

      tailwind의 장점은 아무래도 코드 수가 CSS 문법 대비 적고, tailwindui에서 사용할 수 있는 템플릿이 많다는 점, 그리고 4 버전에서는 Rust 엔진으로 성능이 빨라지고 zero configuration을 지원한다는 점 등이 장점이 될 것 같습니다. [참고](https://daily.dev/blog/tailwind-css-40-everything-you-need-to-know-in-one-place)

      저도 tailwind를 많이 썼었고 좋은 도구라고 생각합니다. 다만, 저는 지금은 팀에서는 sass를 쓰고 있어요. 이유는 디자인 시스템을 만들면서 직접 css를 커스텀 해 주어야 할 일이 많은데, mixin 같은 것들을 만들어서 쓰기에 용이하다는 장점이 있어서 sass를 사용하고 있습니다. (그리고 tailwind가 css를 100% 지원해 주지는 않는 것으로 알고 있어요. 이건 제가 몇 년 전에 쓸 때 기준이라 지금은 개선이 되었을 수도 있습니다!)

      • zero configuration: 설정 파일을 수정하거나 복잡한 초기 설정을 건드리지 않고도 바로 사용할 수 있는 상태
      • 만약 tailwindCSS를 사용한다면 좀 바닐라..? 스타일..?을 적용해도 될 듯. 그냥 바로 태그내에서 설정해주면 코드가 너무 더러워진다고 생각함
        • @apply 를 활용해서 css 파일에서 클래스 혹은 아이디명에 속성을 부여해주고 태그에 클래스네임 부여해도 될 것 같다는.. 그런
          • 다만 다른 tailwind 지원 확장자처럼 클래스네임에 스타일 이름 적용할 때, css에서 설정한 스타일 이름에 대해선 자동완성 기능이 없기 때문에 이런 방식은 생산성이 조금 떨어질 수 있음
      • 캐싱 o
      • 개인적으로 개발적인 측면에선 state를 활용하기엔 tailwind가 좀 더 편하지 않나 생각이 들긴 함.

    • styled-component

      • js를 객체로 관리해 번들 크기가 커질 수 있음
      • styled-components는 런타임에 스타일을 생성하기 때문에 캐싱 전략이 어려움
      • 동적인 스타일 적용 가능 → 우리 프로젝트에서 동적인 스타일 적용을 할만한 부분들이 있는지 생각해보는 것도 중요할 듯 ?
      • 코드 가독성이 좋음

    ⇒ 개인적으로는 blockly의 패키지 사이즈가 크기도 하고, 프로그램 크기 자체가 좀 커질 수 있다고 생각하여 가벼운 tailwind가 낫다고 생각

    프로젝트에서의 핵심 라이브러리

    • Blockly
      • blockly api를 통해 사용자가 블록 동적 생성 가능
    • react-frame-component

    상태관리

    • 사실 상태관리가 크게 필요할까? 라는 생각이 있었음

      → 하지만 1차적으로는 자동저장이 되지 않고 사용자가 저장버튼을 눌러야하니 스타일블록 추가나 추가적인 변경사항에 대한 정보를 클라이언트측에서 가지고 있다가 저장할 때 서버로 보내주는 방식이 좋지 않을까?

      → 탭이 많은 프로젝트이기도 함

    • zustand

      • 러닝커브 ↓

    • redux 부덕ㅅ…

    그외

    • storybook..?

    BE

    프레임워크 + 라이브러리

    • Express
      • 빠르게 백엔드를 구축하고 확장할 수 있다.
      • 자유도가 높은 프레임워크이다보니 컨벤션을 맞추기 어렵다.
      • 타입스크립트 지원이 없다.
      • 초기 설정이 어렵다. (기본적으로 세팅되어있는 라이브러리가 없다보니, 일일이 설정해줘야한다.)
      • 러닝커브x → 적어도 조금씩 써보았다보니..
      • 프레임워크가 가볍다.
        • 간단한 crud 정도의 서비스만 처리하거나, 서버 성능을 고려하면 express가 좋음
    • NestJS

      • 타입스크립트가 기본적이다보니 초기설정의 부담감이 적다.

      • HTTP 연결, DB 연동, 미들웨어 구축, 인증 보안 등 RESTful api 서비스를 제작하기에 필요한 기능들을 기본적으로 제공하고 있다.

      • 필요한 클래스를 일괄적으로 자동생성해주는 명령어 제공

      • 스웨거 문서를 자동으로 달 수 있다.

      • 러닝커브 존재..

        • spring과 유사한 느낌 + nestJS를 해본 팀원이 없다.
        📖

        다만 선택해서 사용하는 기반 서버 플랫폼(Express 나 Fastify)에 대한 지식이 어느정도 필요하고, NestJS 에서 기본적으로 사용하는 의존 라이브러리들(rxjs, class-validator, jest 등)에 대한 지식도 가지고 있어야 사용이 수월합니다. 대부분에 대해 지식이 없는 상태라면 러닝커브가 생각보다 클 수 있겠습니다.

        https://medium.com/naverfinancial/nestjs-%EC%82%AC%EC%9A%A9-%EC%86%8C%EA%B0%90-f851527f7922

      • 생산성이 좋다.

    • [비교](https://wikidocs.net/148195)
    구분 Express NestJS
    유연함, 확장성 Express는 가볍게 테스트용 서버를 띄울수 있습니다. 아이디어를 빠르게 검증하는 데에는 좋겠지만 단순하고 자유도가 높은 만큼 자기에게 맞는 라이브러리를 찾기 위해 발품을 팔아야 합니다. 보일러 플레이트를 미리 얹어 놓은 깃허브 리포지토리들이 있으니 이를 활용해도 좋습니다. 미들웨어, IoC, CQRS 등 이미 많은 기능을 프레임워크 자체에 포함하고 있습니다. 사용자는 문서를 보고 쉽게 따라할 수 있습니다. 원하는 기능이 없다면 다른 라이브러리를 적용해서 사용하면 됩니다.
    Typescript 지원 추가 설정을 통해 사용가능합니다. 기본 설정입니다. 바닐라 자바스크립트[1](https://wikidocs.net/148195#fn:vanilla_javascript)로도 작성 가능합니다.
    커뮤니티 가장 큽니다. 꾸준히 증가하고 있습니다.

    • 개인적인 생각

      • RESTful api를 제작하는데에 있어 생산성과 스웨거 문서를 자동으로 생성해주는 것, 초기설정의 부담감이 적다는 것이 굉장히 큰 메리트로 다가오긴 함.
      • 하지만, 러닝커브와 1차적으로는 우리 프로젝트에 사용자 인증이 크게 중요하지 않다는 점, 많은 api가 필요하진 않다는 점을 고려하면 express가 더 낫지 않나 라는 생각도 든다

    • sequelize

      • 모델 생성이 편리함
      • 원시 sql 쿼리 사용 가능
      • 개인적인 후기: typescript로 쓰기 더럽게 어렵다. 오류가 아주..

    • typeORM

      • typescript 수용
      • 데코레이터 활용으로 엔터티와 관계 정의 가능

      https://npmtrends.com/sequelize-vs-typeorm

      • 이제 엇비슷한 것 보니 타입스크립트 사용이 늘어날수록 typeorm으로 바뀌어가는 추세가 아닐까? js를 쓰면 확실히 sequelize가 편할 것 같은데

        image.png

    DB

    • MongoDB
      • ncp cloud DB for MongoDB 사용
      • 프로젝트 상태 정보를 프로퍼티가 많은 json형태로 저장해야하다 보니 NoSQL 형식이 적합하다고 생각.
    • SQLite
      • 동시편집이 가능해지면 사용
      • 무겁게 MySQL을 사용할 필요는 없다고 생각
    • Redis
      • 동시편집이 가능해지면 사용

    배포 및 클라우드 서비스

    • nginx
      • ssl/tls 지원 → https 설정 가능
      • 단일 서버에서 여러 어플을 같이 올릴 수 있음 (프론트/백 서버 분리 필요x)
    • docker
      • 컨테이너 가상환경
        • 호스트 서버에 영향 x
    • github actions
    • ncp server

    프로젝트 이름

    https://chatgpt.com/share/67211136-73d0-8008-af7e-721ffb446812

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

    웹블럭탕 아니면 태그사시미 아니면 태그돌잔치ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

    Web31-webBlockTangtang

    Web31-sashimiTag

    Web31-FistBirthdayPartyOfTagBaby

FE / BE 컨벤션

https://react-icons.github.io/react-icons/

🏠 Home

🔍 세부 기능

🚀 프로젝트

⭐ 팀 목표

🤝 협업

📖 BooLock위키

J018_권나연
J189_이영재
J190_이유진
J252_최경일
J281_홍현지

🎙️ 발표

💡 회고

🗣️ 회의록

0️⃣주차
1️⃣주차
2️⃣주차
3️⃣주차
4️⃣주차
5️⃣주차

📷 갤러리

Clone this wiki locally