패스트캠퍼스 강의를 정리한 내용입니다.
"The RED : 프론트엔드 Back to the Basics : 지속 가능한 코드작성과 성능 향상법 by 김태곤"

개발환경

git vs svn

알아두면 좋은 것들

• 주요 명령어
• 저장소 만드는 방법
• 코드 commit & push
• branch 작성, 전환, 병합, rebase 방법
• commit message 잘 작성하는 방법

추천 참고 자료
'좋은 깃 커밋 메시지를 작성하기 위한 7가지 약속’ - NHN 기술 블로그
‘지옥에서 온 깃’ - 생활코딩 무료 강의
'팀 개발을 위한 깃, 깃헙 시작하기' - 한빚미디어 출간 서적

git을 지원하는 그래픽 인터페이스 애플리케이션

• 무료 : 소스트리, 깃헙데스크톱, 톨토이즈깃, 비쥬얼스튜디오코드 확장프로그램(제한적 기능 제공)
• 유료 : 크라켄

그래픽 도구는 외부 업체에서 만드는 것이므로 그래픽도구가 지원하지 않는 기능이 있을 수 있음. 텍스트 환경의 깃은 공식 오픈소스라 문제가 생겼을 때 텍스트 환경에서 해결하는 게 더 빠를 때가 있으므로 텍스트 환경에서 하는 방법도 알아두면 좋음

package manager

• 개발 과정에서 설치해야 할 도구나 라이브러리를 각각 설치하고 업데이트까지 주기적으로 하는 것은 번거롭고 어려우므로 패키지 매니저를 사용
• 패키지 매니저를 사용하면, 명령어 한줄로 여러 라이브러리를 한 번에 설치, 삭제, 업데이트 가능

Mac iterm

맥용 터미널 보조 프로그램

Virtualbox

여러 OS를 가상화하여 사용할 수 있는 가상화 소프트웨어

Node.js

• 최신 기능은 미리 익혀 두는 게 좋음 (여러 버전의 노드 경험해보기)
• 메이저 버전이 변경되면 상위와 하위 호환 둘 다 안되는 경우가 많음
• NVM, N
  • 여러버전의 Node.js를 관리해주는 애플리케이션
  • 둘 다 맥과 리눅스에서만 가능

녹화 애플리케이션

• 작성한 UI가 어떻게 동작하는지 설명할 때 스크린캡쳐 이미지로 부족할 때가 많으므로, 커서의 동작까지 나오는 영상 녹화 가능한 어플리케이션 사용
• OS 환경에 따라 본인에게 맞는 애플리케이션 찾아보기

---

프론트엔드 개발자란

• 애플리케이션이 사용자와 맞닿는 접점을 만들고 책임지는 사람
• 개발자는 프로그래밍이라는 도구를 가지고 사용자가 원하는 목표을 달성할 수 있도록 도와주는 사람이며, 프론트엔드 개발자는 이러한 목표를 위해 클릭이나 드래그드랍과 같은 인터렉션을 정의하고 시각적인 용어를 정의하고 재사용 가능한 컴포넌트 만드는 사람
• 다양한 사용자들이 웹 애플리케이션을 차별없이 사용할 수 있도록 다국어 환경과 다양한 화면크기는 물론 사용자의 시각장애나 운동성 장애까지 고려해서 어플리케이션을 만드는 사람
• 포토샵 스케치 제플린과 같은 시각 디자인 도구 뿐만 아니라, 시스템 영역인 배포 스크립트, 배포환경에 대해서도 알아야 하며 사용자가 불편을 느끼지 않도록 사용자 경험에 대한 지식도 갖춰야 하므로 그만큼 다양한 분야를 폭넓게 다뤄야 하는 개발 분야
• 애플리케이션의 인상을 담당하며 사용자와 직접적인 연관이 있는 분야

  예를 들어, 성능이 좋은 진공 청소기!
  성능이 아무리 좋아도 조작이 어려우면 수요가 많을까?
  성능이 좋아도 좋은 평가를 받을 수 없음
  또 다른 예로, 카카오뱅크
  처음부터 사용성을 강조하며 런칭함
  편리하기 때문에 많은 인기를 얻어 성공함

프론트엔드의 현재

사용자가 직접 보는 비주얼 요소를 다루니 디자이너와 협업할 일이 많고
일반적인 프로그래밍 스킬은 물론, 비즈니스 로직도 많이 다루므로 백엔드 지식도 상당수준 요구함

웹 애플리케이션에서 데이터베이스, 파일, 인증을 제외한 부분은 거의 프론트엔드로 옮겨오는 추세라 프론트의 역할이 나날이 커짐

Html5, css3라고 부르던 명세는 이제 없다고 봐야함
Html 명세가 지지부진하게 개발되니 2004년에 애플 모질라 오페라 등 주요 제조사 브라우저들이 모여 WHATWG라는 컨소시엄 구성
2008년에 html5 초안 작성 후 몇 년간의 논의 및 개발을 거쳐 2014년 최종 권고안 발표
이후 html5는 WHATWG에서 개발을 담당하게 됐고 이제 html은 버전이 사라지고 계속 변화하는 living standard가 됨
W3C에서 2017년에 발표한 마지막 명세에는 html 5.2로 버전을 명시하고 있지만
계속 변화해서 가장 최신 명세는 2020년에 갱신되었음
W3C에서 마지막 발표한 CSS는 2.1버전, CSS3라는 버전은 없고
이제는 CSS는 기능별로 모듈별로 나뉘어져서 각 모듈의 버전이 있고 개별적으로 발전하는 형태가 되었음

프론트엔드 개발자가 힘든 이유..
프레임워크를 비롯한 기술 트렌드가 자주 바뀜
Grant, gulp 등의 작업도구 > 웹펙과 같은 번들러 > 웹팩 설정 어렵다고 새로운 번들러 파셀(Parcel) 등장

배워두면 좋은 기술

• 타입스크립트
• 리액트 네이티브 : 모바일 애플리케이션 작성 가능
• 일렉트론 - 데스크톱 애플리케이션을 만드는 오픈소스 프레임워크
  • 데스크톱 애플리케이션 개발을 위한 앱 기술 : html, css, js
  • 가벼운 메모 어플리케이션, 개발자용 에디터, 그래픽도구, 게임까지 개발 가능

공부 방법

• 영역을 넓혀가되 중요한 것을 깊이 있게!
  → 공부 범위 축소 (국영수 위주)
• 공식문서 읽기 (교과서 위주)
  • html, css, javascript와 같은 기초 웹 기술은 모질라 재단에서 제공하는 개발자 네트워크 문서 참고
  • vue, angulr, react는 각 프레임워크 공식문서
  • 한번에 완벽히 읽기보단 자주 읽는 것이 더 중요 (여러 번 보면 안 보이던 것이 보이니까!)
• 코드 많이 읽기
  • 실무에서 이미 구축된 시스템을 바탕으로 작업을 하는 경우가 많은데, 이때 아무리 좋은 방법이라도 구성원과 합의가 안되어 있으면 방해물에 불과하므로 기존 코드의 규칙을 잘 따르는 것이 중요
  • 다른 사람의 코드를 읽는 연습을 많이 해두면 실무에 아주 많은 도움이 됨
• 개인 프로젝트 해보기 (혼자 또는 소수의 인원)
  • 프레임워크 최신 버전 써보기
  • 인기있는 기술 써보기
  • 프로젝트 선정은 지금 나한테 가장 필요한 것 만드는 것으로!
    → 나한테 유용하다면 중간에 포기 안하고 끝까지 완수할 동기가 됨
  • 프로젝트 아이디어 틈틈히 메모해두기
  • 면접 볼 때 잘 모르겠다는 것 보다 간단하게라도 사용해 보았다고 하는 게 더 낫고, 장단점까지 설명할 수 있으면 베스트! 따라서 다양한 기술을 경험할 것
• 어느정도 알고 있는 기술이라면 글로 남기기 (블로그)
  • 잘 알고 있는 기술이라도 실제로 글로 쓰거나 다른 사람한테 설명할 때 어려울 수 있으므로 불특정 다수를 대상으로 기술 설명하는 연습해보기
  • 기술블로그 작성 TIP

    • 정확한, 검증 된 지식만을 전달하기
    • 필요 시 예제 코드 작성하기 (글을 더 풍부하게 해줌)
    • 필요 시 참조 링크 추가로 글에 신뢰성 더하기
    • 문장을 짧고 정확하게 작성하기
      (문장이 길어지면 집중도와 흥미가 떨어질 뿐!)

• 깃헙 트렌딩 페이지 자주 참고하기
  → 일정 기간동안 가장많은 스타를 받은 프로젝트 확인
• 트렌드를 정리해서 보내주는 메일링 리스트 구독
• 프론트엔드 분야에서 유명한 SNS 계정 팔로우 (트위터)
  → 가능하면 영문으로 된 정보 보기
  → 다 읽으려고 하지말고 제목 정도만! 자주 눈에 띄는 것이 있는데 그게 추세!
  → 이왕이면 해외트렌드 읽기
• 채용공고를 통해 어떤 기술이 기업시장에서 대세인지 확인
• 라이브러리나 프레임워크 사용할 때, 이 기술을 왜 만들었나 살펴보기
  → 어떤 문제를 해결하려고 만들었는지.. best practice(모범사례)나 기술의 디자인 컨셉 등 살펴보기
  → 일부러 망가뜨려 보거나 조금씩 변형해가며 원리 익히기
  → 단순히 복사해서 사용하더라도 코드 행간에 숨겨진 이유 발견하기. 즉 원리 이해하기!!

프로젝트 진행 TIP

백엔드는 인풋과 아웃풋만 정해진대로 나타나면 개발자가 아닌 이상 관여하기 힘든데
디자이너나 프론트엔드 결과물에는 누구나 의견을 낼 수 있음
1px 차이까지 요청 받아 수정한 경험이 있다면… 이럴 때 다음과 같은 방법을 추천

1. 자주 사용하는 스타일을 컴포넌트화 하기
자주 사용하는 프로그래밍 코드를 라이브러리로 만들어 두듯이, 자주 사용하는 스타일을 컴포넌트로 만들고 나중에 이들을 조립해서 사용하기
이 때, 이 과정은 디자이너와 함께 협의! 서로 합의된 컴포넌트를 기반으로 애플리케이션을 만들어 나가는 것.
이런 방법은 atomic 디자인과 통하는 개념이며 React나 Vuejs 같은 모던 프레임워크는 이런 컴포넌트화가 용이하게 되어 있음

2. MVP, 실행 가능한 최소 단위의 프로덕트 만들어 보기
스티븐잡스가 말하길, '대부분의 사람들은 제품을 보여주기 전까지 자신이 뭘 원하는지 모른다'
프론트엔드 개발자로서 우리는 비주얼 요소 만들고 인터렉션 더하는 것. 이때 컴포넌트화 해놓은 것이라면 논의가 끝난 후이지만 그게 아니라면 무수한 피드백을 감당해야함…
꼭 필요한 부분만 최소로 구현하고 의견 받고 수정하는 과정을 반복하기
‘애자일 방법론 적용’ 참고하기!
핵심은, 피드백과 수정은 피할 수 없으니 최소 규모로 자주 반복하기
한 사이클에서 개발할 규모가 작아지니 일정 측정도 쉬워지고 진척도 보고도 용이함

3. 가능하다면 API는 프론트엔드 개발자가 설계하기
백엔드와는 API 위주로 협업을 하게 되는데, 이 때 API 설계는 누가 담당할지 모호하나
편하게 데이터를 받으려면 프론트에서 정의하는 게 좋음
백엔드 개발자와 API에 대해 협의하고 입출력을 정의하는 것은 프론트엔드 개발자가 갖출 최소한의 백엔드 지식!

4. 스스로에게 득이 되는 대화법 사용하기
예를 들어 협업 부서로부터 다음과 같은 질문을 받았을 때
Q: 이 에디터 3개월만에 개발 되나요?
‘안된다’ 보다는 ...

• 조건 변경 : 예) 9개월이면 가능하겠네요
• 요구 협상 : 예) 굵게 기울게 밑줄 등의 기능만 있으면 3개월 가능합니다

→ 요구 기간내 불가능하다는 결과는 비슷하지만 부정적인 사람이 아닌 긍정적인 사람으로 인식될 수 있음