Post

원티드 프리온보딩 - 클린코드2

Posted Updated
By hyemin 10 min read

원티드 프리온보딩 - 클린 코드 2강

다른 사람들이 생각하는 클린코드는?

  • 빠르게 이해할 수 있는 코드
  • 확장성
  • 가독성
  • 명확한 목적성과 역할
  • 기능에 충실한 코드

일관성이 중요한 이유

나쁜 코드라도 일관성만 잘 지킨다면 자동화도 할 수 있기 때문에!

  • 일관성이 명확하다면 편집기, 정규식 조합으로 한번에 고칠 수 있다.
    • JSCodeShift 까지 활용한다면 덤
  • 실무에서는 일관성이라는 규칙을 정하기 위해 논의해야한다.
  • 규칙으로 정한 일관성은 어떠한 경우에도 깨지 않도록 노력해야한다.
  • 일관성은 향후 문서화로 표현하고 Lint로 강제할 수 있다.

Style Guide

네이밍 컨벤션을 포함하는 규칙을 위한 가이드라인으로 하나의 팀 혹은 집단을 위해 존재
즉, 협업에 큰 도움을 주기 위함

장점

  • 서로를 이해하기 위한 시간 절약
  • 코드 품질
  • 일관성
  • 가독성 향상
  • 유지보수 용이성

예시

■ 상수

  • 필히 이미 선언된 상수가 있는지 확인하고 가능하면 컴포넌트 외부로 분리하여 관리
  • 상수의 위치는 import 묶음 바로 밑에 위치
  • 상수는 객체로 묶어서 as const와 함께 사용하는 것을 권함
1
2

const DEFAULT_TICK = 100;
const DEFAULT_DELAY = 500;

■ 컴포넌트 Props는 interface 사용

  • 컴포넌트 Props Typing은 항상 컴포넌트 바로 위에 위치
  • I-Prefix, T-Prefix 금지!
1

interface SomeComponentProps {}

■ 파일명과 컴포넌트명을 일치 시키기

  • 컴포넌트 Props는 항상 컴포넌트 바로 위에 위치
  • 모든 주석은 @(어노테이션)과 함께 작성_ https://jsdoc.app
1

const SomeComponent = ({ prop1, prop2 }: CatchComponentProps) => {};

■ 예측이 어려운 Flag는 만들지 않는 것이 좋음

  • 꼭 필요하다면 useRef() useState()를 활용

■ 상태는 꼭 필요할때만 만드는 것이 좋음

  • 렌더링에 영향이 없다면 useRef() 사용
1

const [state, setState] = useState("someState");

■ 렌더링 방지할 때 Fragment<></>보다는 null을 사용하기

1
2
3
4
5
6
7
8
9

// BAD!
 if (isHold) {
    return <></>;
  }

// BEST!
  if (isHold) {
    return <null;
  }

■ useEffect()는 Main JSX와 가장 가까운 곳에 위치

1
2
3

useEffect(() => {
  // dependency arrays 관리시 감지 가능한 상태인지 필히 확인한다.
}, []);

참고하면 좋은 레퍼런스

불필요한 개선보다는 필요한 일을 찾아서 하자.

인기 많은 서비스에서의 리팩토링은 정말 힘들고, 리팩토링해야하는 근거가 필요하다.

취준생인 경우에는,

점진적인 리팩토링 훈련을 해보자.

■ 예시 1

  1. JS만으로 컴포넌트 만들기
  2. Web Components로 만들기
  3. 만든 컴포넌트 배포 하기
  4. 배포한 컴포넌트 직접 가져다 쓰기

■ 예시 2

  1. MVC XXX앱 만들기
  2. Controller 제거해보기
  3. Proxy API 활용하기
  4. Virtual DOM 라이브러리 도입해보기 (Snabbdom)
  5. JSX Parser 구현해서 사용해보기

문제를 정의하고 달성하자.

■ 개발을 모르는 유저를 위한 기능 늘려가기
https://www.instagram.com/p/CrvUNktLDbM

■ 개발자를 위한 라이브러리 만들며 확장하기
https://github.com/sgsg9447/react-check-in-out-calendar-core

나는 어떤 마음 가짐으로 코드를 작성하는가,

  • 도구에 매몰된다
  • 패턴에 매몰된다
  • 요구사항 분석이 아니라 패턴이나 기술부터 정하고 시작한다
  • 고민할 시간에 남들을 따라한다
  • 나도 모르게 클론 코딩한다
  • 남이 공부한 자료를 생각 없이 따라 적용한다

■ Hype Driven Development - 설레발 주도 개발

https://lazygyu.net/blog/hype_driven_development

요구사항이나 구조 설계같은 문제 해결을 생략한다.

  • 현실에서 마주한 문제를 기술적으로 잘 해결하는 훈련을 많이하는 것이 가장 중요하다.

기술을 선택하는 과정도 공부이다.

  • 무조건 프로젝트를 시작했을 때, 최악의 경우 프로젝트의 요구사항이나 기획을 특정 프레임워크에 맞춰 변경해야할 수도 있다.

■ 자바스크립트 에러의 종류, 런타임 vs 컴파일의 차이는 알아야한다.

개발자가 성장하려면 학습에 막힘이 있을때 적어도 내가 뭘 모르는지는 알아야한다.

■ 보이스카웃 규칙

떠날 때, 찾을 때보다 캠프장을 더욱 깨끗이 하라.

  • 레거시를 비난하고 불평할 시간에 그 코드를 개선하자.
  • 잘 만드는 사람이 있고 잘 고치는 사람이 있다.

■ 기술 부채의 대물림

보이 스카우트의 규칙을 실천하고 기술 부채를 직접 끊어내자

  • 최소한의 노력이나 점진적 개선이라도 해보자

■ 상속보다는 확장

Extends
수동적으로 물려받는다는 생각은 사고의 흐름을 막는다.

  • 확장하면 오히려 더 많은 기능을 추가할 수 있다.

■ KISS (Keep It Simple Stupid)

단순하게 유지하고 불필요한 복잡성을 피하여 단순하게 만드는 것을 권장

  • 복잡성이 더 높은 코드일수록 확장하기도 유지 보수하기도 더 어려워진다.
  • 간단하고 이해하기 쉽지 않다면 빨리 쓸모없어져서 쓸모가 없게 될 수 있다.
  • 사용자가 제품을 이해하지 못하면 그 제품을 사용하지 않는다.
    • 바쁜 삶을 사는 경향이 있는 사용자가 복잡한 디자인을 빨리 포기한다.

■ YAGNI

초기에는 중요한 것들에만 집중하고 필요할 것이라고 예상되는 것은 절대 구현하지 말라

  • 필요하다고 판단될 때까지 기능을 추가하지 말 것을 강조하는 프로그래밍 원칙
  • 오버엔지니어링을 방지하고 불필요한 리소스를 절약한다
  • 아직 이해하지도 못하는 것을 설계하는 것은 최악의 행동이다.

■ DRY (Don’t Repeat Yourself)

반복을 줄이고 코드베이스를 보다 관리하기 쉽고 효율적으로 만드는 데 초점

  • 즉 같은 코드가 반복되는 것을 막으라는 뜻 ⇒ Copy & Paste 한 곳에서만 코드를 변경한다면 참조하는 모든 곳에서는 변경사항만 관리하면 된다.

  • 유지보수와 버그가 줄어들어 리소스를 절약할 수 있다.

■ 횡단 관심사 (cross-cutting concern)

횡단 관심사는 일반적인 관심사의 분리와는 다르게 뽑아낼 수 있다.

관련 블로그 글 https://hellomooneekim.netlify.app/%ED%9A%A1%EB%8B%A8%EA%B4%80%EC%8B%AC%EC%82%AC/

■ 단일 책임 원칙

OOP에서 단일 책임 원칙이란 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다.

  • 함수, 컴포넌트 등 수 많은 곳에 존재할 수 있는 모든 코드에서도 한번에 한가지 일만 수행하도록 할 필요가 있다.
원티드-프리온보딩, 클린코드
Pre-onboarding 클린코드
This post is licensed under CC BY 4.0 by the author.