쉬어가며.. 클린코드란? feat.멘탈모델 / 설레발 주도 개발

취준을 하며 면접도 봤고, 사이드프로젝트도 진행중이다.
사이드 프로젝트를 진행하면서 TDD를 접목시키면서 STORYBOOK, JEST를 사용하며 손에 익히는 가운데
원티드에서 이번에 클린코드 관련 프리온보딩을 한다기에 신청을 하였다.
 
1주차 에서는 클린코드란 무엇인가?
그리고 스타일가이드, 멘탈 모델.. 개선할 점들에 대해서 배우게 되었다.
이러한 것들을 다시 한번 정리해보려한다.
내가 알던것들이 전부가 아니였고... 내가 아는것도 맞는게 아니였다...!
 

클린코드란?

- 처음 클린코드란에 질문에 수백명이 많은 프론트개발자들은 각기 생각하는 클린코드가 달랐다. 크게보면 같은것 같기도 하다.
- 누구나 처음봐도 이해하기 쉬운 코드, 즉 직관적인 코드
- 확정성이 좋은 코드 (유지보수가 좋은?)
- 가독성이 좋은 코드
- 성능을 고려한 코드
- 크로스 브라우징을 고려한 코드
 
그 외에도 여러가지가 있을것이고 이러한 클린코드를 위해 팀들과 컨벤션을 통해서 전반적인 규칙, 관습을 만들 수 있다.
* 저장소, 폴더, 파일, 함수, 변수, 상수, 깃 브랫치, 커밋 등등
 
리액트 컴포넌트를 예시를 보자 ( 정답은 아닙니다.. )
- 이미 선언된 상수가 있는지 확인하자 (가능하면 컴포넌트 외부로 분리하여 관리)
- Props는 interface를 사용 / 항상 컴포넌트 바로 위에 위치
- 컴포넌트는 PascalCase 표기법 사용
- 불필요한 Flagment사용 금지
 
이러한 가이드, 레퍼런스들은 팀마다 다를 것이고 프로젝트마다 어떻게 정하느냐에 따라 다르다.
저번 팀프로젝트에서 한번은 우리 에어비앤비를 따라볼까? 라는 이야기가 나왔지만 바로 접게되었다..
이러한 강한 규칙들은 오히려 프로젝트를 하면서 코드를 작성할때도 작업속도를 늦추게되고, 불필요한 것들이 생길 수 있다.

---

그럼 여러 방식들에서 예를 살펴보자. (이것 또한 정답은 아님)

count++; vs count += 1; vs count = count + 1;

- 개인적으로 나는 첫번째를 선호한다.
- 그러나 어떻게 보면 가장 보기 쉽고 예측하기 쉬운 것은?  count = count + 1; 
- 대부분의 개발자들이 런터임에러를 굉장히 많이 낸다고 한다. 이 이야기는 뒤에 다시 자세하게 이야기해보려고 한다.
 

if (isLogin) {} vs if (isLogin === true) {}

- 보통 boolean값이라면 is를 통해서 state값을 선택해여 사용해서 나는 전자를 선호한다. Truthy를 통해서 구분하는게 맞지 않을까? 했다.
- 강사님은 현재 후자를 선호한다고 한다. 수 많은 레거시를 겪으면서 생각이 변했다고 한다.
- 서버에서 내려온 값을 신뢰할 수 없기도 하고( LocalStorage에 문자열로 Ture를 넣어서 사용하거나 다른 값을 사용하기도 한다.) 그래서 팀 내에서는 무조건적으로 Truthy, Falsy값을 사용하지 않는것을 규칙으로 만든다고도 한다.
 

isLogin && <HelloWanted /> vs isLogin ? <HelloWanted /> : <></> vs isLogin ? <HelloWanted /> : null vs isLogin ? <HelloWanted /> : undfined

• isLogin ? <HelloWanted /> : null
• isLogin && <HelloWanted />

- 보통 이렇게 많이 쓰지 않나!?
- length값을 통해서도 하는 사람들이 있지만 0은 렌더를 유발하기 때문에 사용하지 말자!!

---

개발자들이 한번씩 거쳐가는 중2병과 같은 것들이 있다고 한다.
미리 알고 대비해보자..

• 도구에 매몰되지 말자
• 패턴에 매몰되지 말자
• 요구사항 분석이 아닌 패턴이나 기술부터 정하고 시작하지 말자
• 남이 공부한 자료를 생각없이 따라하지 말자
• 고민할 시간을 가지자.. 무작정 컨트롤 c + v 하지 말자

 
그렇게 듣게 된 설레발 주도 개발

HYPE DRIVEN DEVELOPMENT

- 요구사항이나 구조 설계와 같은 문제 해결을 생략
- 요즘 핫한 것들만 따라가고 무작정 따라하는 주니어...
(기술을 선택하는 것도 공부이다. 프로젝트의 요구사항, 기획을 특정 프레임워크에 맞춰 변경해야할 수 있다.)
 
 
프론트엔드의 숙명은 언제나 새로운 기술을 만나게 된다. 이러한 것들은 프로젝트를 시작하고 기술스택을 정할 때부터 어떠한 새로운 기술을 사용할지 고민하게 되는것 같다.
- 설레발 주도 개발을 통해서 생기게 되는 이슈는?
- 유명 블로그, 레딧, 해커뉴스, ... 등을 통해 핫한 것들에 기반을 두고 개발을 시작하게 된다.
- 그 외에도 컨퍼런스에서 이야기하는 것들을 무작정 사용하게 되는..
- 목소리가 큰 한사람에 의해서 시작되는 결단...
 
이렇게 시작 된 프로젝트는 스프린트가 계속 되면서 팀에 도움이 되지 않고 오히려 일이 생길 수 있다.
그렇게 팀은 후회를 하기 시작한다. 새로운 기술 도입이 어떻게 보면 프로젝트에 도움이 되는게 아닌 걸 알게 된다.
 
여기서 알고 넘어가야하는 것은 무조건 새로운, 핫한 것들이 좋은게 아니라는 것, 각 프로젝트마다 맞는 기술스택이 있고 라이브러리, 프레임워크가 있다는 것, 내가 아무리 조사하고 팀들에게 의견을 제시한다고 해도 나중에 되면 큰 후폭풍이 돌아올 수 있다는 것...
역시나 더 신중해야겠다..

---

* 런타임에러는 구분하자

- 프론트엔드 개발자라면 그래야한다.
- 개발자가 성장하려면 학습에 있어서 적어도 내가 뭘 모르는지, 부족한지 알아야 한다.
- 하지만 대부분의 프론트엔드 주니어는 런타임 에러가 무엇인지 모르는 경우가 많다고 한다.
- 아무리 못해도 컴파일과 런타임의 차이는 구분하자 ( 브라우저, 빌드 해석 구분 )
 

컴파일, 런타임의 차이는?

컴파일
- 개발자가 작성한 소스코드를 컴퓨터가 이해할 수 있는 기계어로 변환하는 과정을 의미한다.
- 변환 과정은 컴파일러라는 특별한 프로글매에 의해서 수행되며, 이 과정에서 코드의 문법 검사와 오류체크가 이루어 진다. 컴파일 과정은 코드가 실행되기전에 이루어지며, 이 과정에서 발견된 오류는 컴파일 오류라고 한다.
- 예를 들면 타입스크립트를 통해서 런타임 이전에 에러를 잡을 수 있다.
* Babel, typeScript, Webpack
 
런타임
- 런타임은 컴파일 된 코드가 실제로 실행되는 시점을 의미한다.
- 프로그램은 사용자의 입력을 받아 처리하고, 결과를 출력한다. 런타임에서 발생하는 오류는 대부분 논리적, 예외처리 등에서 발생한다.
* React, Node ...

---

YAGNI - You Aren't Going to Need It
- 초기에는 중요한 것들에만 집중하자! 예상되는 것들을 구현하지 말자
- 필요하다고 판단 될 때까지 기능을 추가하지말자
- 오버엔지니어링을 방지하고 불필요한 리소스를 절약하자
- 아직 이해하지도 못하는 것을 설계하는것은 최악의 행동이다.
 
DRY - Don't Repeat Yourself
- 반복을 줄이고 코드베이스를 보다 관리하기 쉽고, 효율적으로 만드는데 초점을 두자
- 한 곳에서만 코드를 변경하자
- 유지보수와 버그가 줄어들어 리소스 절약이 가능하다.
 
관심사 분리 - Single Responsibility Principle
- 관심사는 추상화의 일종으로 코드에 영향을 미치는 정보 집합이다.
- 관심사가 잘 분리된다면 독립적인 모듈 개발과 확장 그리고 모듈 재사용성을 위한 더 높은 자유도를 확보할 수 있다.
 
르블랑의 법칙 - Leblance's Law
- 나중은 결코 오지 않는다.
- 지금 하자 당장
- 한번 작성한 쓰레기 코드를 나중에 수정할 수 있을까? 중꺽마~~!!!!

---

이번 강의와 주차를 통해서 얻은 점

• 컨벤션을 정하고 지키자
• 코드를 작성할 때 한번 더 생각하자
• 기술 스택을 정할 때 신중하자
• 불필요한 개선보다는 필요한 일을 찾아서 하자 ( 내가 중요하다고 생각해도 아무도 원치 않을 수 있다.. 잊지 말자 )
• 문제를 정의하고 달성하자