[특강] 클린코드

클린코드란?

의식적인 훈련이다.

• 네이밍을 잘 하는 훈련을 해야함 (네이밍을 잘해야 커뮤니케이션이 잘된다.)
→ 동사의 위치를 구분하자.
→ 접미사, 후미사의 규칙을 만들어라. (이상한 규칙이라도 계속 일관성을 지킨다면 다른 사람이 이해할 수 있다.)
→ 번역기 적극 활용.

• 일관성 지키기
→ 이상한 코드여도 일관성이 있으면 고치기 쉽다. ( VScode 단어 검색기능으로 동일한 단어를 한번에 고치기 가능)
→ JSCodeShift 라이브러리를 한번 써보는 것도 좋다. (한번에 코드 일괄변경 가능)
→ 팀끼리 정한 규칙(일관성)은 절대로 깨지 말 것 ( 이때 이런 규칙들은 반드시 문서화해야함)

• 생태계를 잘 알아야 함. (생태계는 다르게 말하면 대중성, 사회적 약속)
→ ‘삼다수바? 우리는 이거를 얼음이라고 부르기로 했어요’
→ 오픈소스 생태계로 쌓인 맥락들과 지식은 무시 불가함. 이때 그 맥락을 무지성으로 따르는게 아니라 이해해야함

• 함수
→ Parameter(매개변수)와 Argument(인자)는 다르다.
→ 함수는 항상 반환이 있어야 하고, 어떤 input을 받아야 함. 반환타입이 없다면 이상한 함수일 가능성이 높음.
→ 반환이 없으면 async await을 써야한다(?)

• 서버를 생각하자.
→ 예를들어 카테고리 목록은 상수일까? 데이터일까? (데이터이다. 상수이면 카테고리 순서를 바꾸기 위해선 배포를 다시해야한다.)
→ 해당 없음(default, 모든 조건문에 부합하지 않는 경우)을 항상 생각

• 점진적으로 개선하자.
→ 해야할 것, 신규로 개발해야할 것은 많고 이미 바쁜데 개선 해야 하는 것은 또 언제 해야하는가? (할 시간이 부족하다. 돈이 되는 과제가 아니라서 기획자 입장에선 중요하게 생각안함. 그래서 점진적으로 개선해야 함)
→ 인기 많은 서비스일 수록 리펙터링은 정말 어렵다.
→ 철저하게 PoC 할 것(기술 검증)
→ 개발을 모르는 유저를 위한 기능 늘려가기 (ex: 개발진스)
→ 개발자를 위한 라이브러리 만들며 확장하기 (ex: 캘린더 만들기)
→ 기술적인 챌린지 하기 (Bottom → Up 방식 추천: 첫 페이지만 SSR 돌도록 직접 구현하기 → 그 다음에 Next JS 쓰기)
→ Bottom Up 방식으로 해야 그 기술을 왜 쓰는지 와닿음

• 타인을 위한 코드 작성하기
→ 한 회사의 개발자는 1000명이 넘어가는 경우가 있다. (그래서 타인을 위한 코드는 매우 중요하다)
→ 기술은 급진적으로 변화하고 새로운 기술은 계속 나오게 되는 시대에서 내가 작성한 코드는 점점 녹이 슬게 되고 레거시 코드가 된다.
→ 구조도를 그릴것 (UML, 피그마 사용)
→ 주석이 없는 코드를 작성하도록 노력할 것 (간혹 특수 케이스에서는 비즈니스 영역은 주석을 남겨도 된다.)
→ 불필요한 코드 지울 것
→ 임시 변수 만드는거 절대 지양할 것
→ 내 코드를 설명하라, 꾸준히 리뷰를 받자, 코드리뷰에 취해있지 말아라, 못해도 한달 후에 알아봐야 한다.
→ 꾸준히 리뷰를 받고 코드 리뷰에 취해있지 마라(예를 들어 한달 동안 개발하는데 한달이 끝나고 나서 갑자기 안된다고 하거나 그때 되서야 리뷰를 받는 경우가 있더라. 그래서 꾸준히 리뷰를 받는 것이 중요함)
→ 뜨겁고 과감하게 논쟁하자. 동의하지 않더라도 헌신해야한다. (회피형이 되지 말자. 일단 맞춰주고 나중가서 수정해야지 하는 마인드 정말 좋지 않더라. 차라리 싸워라. 어떻게든 설득해야 한다.)
→ 책 추천: 질문하는 공부법 하브루타

• 자동화가 중요하다.
→ 예를들어 세미콜론은 ESLint Prettier가 하게 냅두자.
→ ESLint, Prettier, Husky, lint-staged, Editor Config는 기본
→ Custom ESLint도 제작해보라.

• 멘탈 모델
→ 어떤 마음가짐으로 코딩하세요?
→ 요구사항을 먼저 분석하고 분할정복할 것.
→ 실패해도 실패한 만큼만 배포하도록 하고 점진적으로 개선하도록 할 것.
→ A → B → C 까지 해야하는데 B단계까지 했을때 배포가 불가능하지 않게 하라.
• TPO (Time, Place, Occasion)
→ 과제를 할때 아 나는 어떤 멘토님의 코드를 그대로 써서 한번 구현해봐야지! 같은 마인드를 갖지 말고, 구조도 그려보고 요구사항에만 충실하는게 중요하다.
→ 시간, 장소, 상황을 고려하라. (그럼 개발자에게 시간, 장소, 상황은 무엇일까?)
• 보이 스카우트 규칙
→ 떠날 때를 찾을 때보다 캠프장을 더욱 깨끗이 하라.
→ 불평할 시간에 코드를 개선해보자.
• 르블랑의 법칙
→ 나중은 결코 오지 않는다.
→ 지금 이상한 코드 작성했는데 나중이라고 수정할 수 있을까?
→ 그냥 지금 해라. 중꺾마.
→ 근거와 가설을 가지고 토론하라.
→ 어설프게 만들바엔 그냥 라이브러리 갖다 써라

추천 링크

https://github.com/qkraudghgh/clean-code-javascript-ko

질의응답

• 변수, 함수명을 지을 때 고민이 많은데 강사님만의 팁이 있을까요?
→ 무조건 이미 회사에서 많이 쓰이는 컨벤션에 따른다. 번역기 꼭 돌려보는 편이다.

• 코드의 품질 vs 완성도 둘중 어느게 더 중요한가요?
→ 의식적인 훈련이 중요하다. 그냥 알아서 클린코딩을 하도록 노력하자.
→ KISS, DRY 중요

• 프로젝트때 의사소통이 중요한데 추상화된 기술적인 용어들에 대한 이해를 최대한 빠른 시간내에 숙지할 수 있는 방법이 있을까요?
→ 시간을 더 쓰는 수 밖에 없다. 프로토콜 문서도 있다. (그런 단어들을 모두 사전으로 작성하는 경우)

• 최근에는 안다는 것은 무엇일까 라는 생각에 빠져 있는데 이 기술을 정말 알고 사용하는
→ 기술 부채
→ 우리 부모님도 클론코딩하면 대충 다 만드십니다.
→ 지금은 내가 무언가를 만들때 아는게 없어도 만들 수 있는 세상이다. (기술 부채)
→ 이런 행위가 지속되면 기술을 빚진다.
→ 이런 행위를 채워나가는 학습 (Input)
→ 내가 배운 것들을 계층화 해서 나만의 언어로 정리해보자.

• 코드리뷰 잘하는 방법없을까요?
→ 방향을 잘 잡아주세요. 키워드를 적절하게 던져주세요.
→ 정답을 주려는 행위는 가장 악이다.
→ 적절한 질문을 주고 받는게 중요하다.
→ 피드백을 핑퐁하는게 가장 중요하다.

• 레거시 코드여도 그냥 냅두는 경우
→ 대부분 레거시 코드가 더 안전하다.
→ 뒤집어 엎으려다가 회사에 엄청난 손해를 끼칠 수 있기 때문
→ 그래서 점진적인 개선 방법을 습득해야 한다. (10%하고 배포, 50%하고 배포…)

• IPrefix와 TPrefiex 써야하는지 말아야 하는지?
→ 타입이랑 interface 구분할때만 쓴다.
→ 마소에서는 사용하지 않을 것을 권장한다.

• 비전공자인데 CS지식을 어떤식으로 채워나가야 할까요?
→ 최소 네트워크는 챙겨가주세요.
→ 그 중에서도 FE 개발자가 알아야할 부분만 쏙쏙 공부하세요.
→ Axios는 무엇의 확장 구현체인지 아는가?
→ Axios와 fetch의 차이는 무엇인가요? (라이브러리이냐 표준 API이느냐)
→ Axios는 XMLHTTPRequest를 잘 쓰기위한 구현체더라.

• 실제 회사에서 팀장이 바쁘다는 이유로 코드리뷰를 하지 않는다면 어떻게 해야하나요?
→ 그런 회사는 애초에 코드리뷰가 없어진다.

• 모르는 것에 대해 창피해 하지 않는 방법?
→ 무지를 적절하게 드러내는 멘탈이 필요함
→ 당당하게 모름을 드러내는 뻔뻔함이 있어야 오래 일할 수 있드라.

• 신입이 가져야하는 자질?
→ 요즘 신입, 경력 구분잘 안함
→ 종이처럼 투명해서 습득력이 좋은 사람
→ 적극적이고 주도적으로 팀에 긍정적인 기운을 주는 사람
→ 불필요한 허세나 기술에 취해있는 것들은 쓰지 말 것.

• 인상적인 지원자가 있었다면?
→ 블로그나 학습했던 기록이 정말 남다른 사람들
→ 깊이 있게 학습하려고 노력했던 흔적
→ 대부분은 책 본 후기 챕터 1 이런게 대다수긴 함

• 모르는게 있으면 삽질하고 물어보라고 말하는데 어느정도 삽질을 해야하는지?
→ 상한선은 딱히 정해진게 없다.
→ 계속 혼자서 문제 해결하기위해 훈련해야함.
→ 코테 알고리즘 공부할때도 쉬운문제 매일 1문제 풀기보다 어려운 문제 일주일동안 1개 풀기가 더 효과적이더라.

• 신입 개발자의 필수 기술 역량?
→ 가지 수에 집착 X, 깊이에 집착할 것
→ 기술 스택을 add할 생각만 하지 말고 nested 할 생각하세요.
→ 내 시간은 한정적이고 무언가를 추가적으로 공부한다는 것은 이득이 아니라 그 시간에 다른 걸 못한다는 것을 인지해야함 (Trade Off).
→ 면접관 입장에서 오 이런 고민도 했네? 오 여기까지 만들어봤네? 오 내가 못한 그 이상으로 해봤네? 경력자보다 나은 것 같은데? 이런 생각이 들게 하라.
→ Know & How가 모두 들어간 사람은 정말 좋은 회사 간다.
→ 그 기술을 어떻게 적용했고 트러블 슈팅(공식문서만 읽어도 해결 가능한 문제 제외)부터 구현 단계 까지 어떤 것을 해냈는지 술술술 말함
→ 그 배경의 언어적 컴퓨터 공학적 기술까지 알고 있으면 좋음