JUMPIT TO FRONT-END 온라인으로 봤다~

점핏에서 프론트엔드 개발자 이야기를 들려주는 토크 콘서트를 했다. (개.취.콘 !)
참여 신청하면 추첨을 통해서 오프라인으로 참여할 수 있었는데, 나는 추첨에서 탈락해서 ㅠㅠㅠ 온라인으로 봤다.

좋은 내용, 적용하고 싶은 내용이 많았다 ㅎㅎ 강연 들으면서 요약해 봤고, 내 생각은 보라색 형광펜으로 칠했다. 

좋은 강연을 제공해 주신 점핏 & 강연자 님들께 감사하다 ㅎㅎ

https://www.jumpit.co.kr/book-concert/12

점핏

 

<FE 개발자의 소프트 스킬과 하드 스킬 (김태곤 님)>

• 능력 = 하드스킬+ 소프트 스킬
• 좋은 코드
  1. 테스트하기 용이(쪼개기 등)
  2. 읽기 쉬움(가독성) -> 내 코드를 다른 사람이, (합의 하에) 한국어 변수명도 가능.
  3. 일관성(이름, 파일 구조 등 / 합의 중요)
• 테스트 코드는 가능한 부분부터 적용하자.(일이 바빠서 테스트 코드 작성할 시간 없다고 했는데, 완전 공감. -> 조금씩이라도. 리팩토링 전, 버그 수정 후 등에라도)
• 한 커밋에는 한 가지 일만! (다른 코드 수정하고, 리팩터링 하고 싶더라도) - 추적 용이
• 본인만의 학습 방법, 루틴 마련하기.
• 가장 좋은 공부법은 본인이 다른 사람을 가르치고 설명하는 것
• 답답해 보이는 코드라도.. 이유가 있다.
• 프런트엔드 개발자는 UX에 대해 고민하고, 다른 방법을 제시할 수 있어야 한다.
• 거절할 때 안된다고만 말하지 말기. 오랫동안 고민하는 척(?) or 고민하기 - 대안 제시 -> 이득이 됨.
• 이직은 계속 준비해야 한다. 이력서 업데이트, 경험 삼아 면접 보기.
• 커리어 = 시간 + 스토리 (연차는 나이 같은 것이라고 하신 부분이 와닿았다! 찰떡 비유! 나이가 많다고 저절로 발전하고 성장하는 건 아님.)
• 가능하면, 자신의 기술이 메인으로 사용하는 회사로 가는 게 좋음.
• 도메인 지식 빨리 배우려면? 코드를 많이 읽어야 함!
• 인간은 실수를 한다. 실수를 막아줄 수 있는 도구, 시스템을 사용하자. (linter, typescript..)
• 문제를 작게 나누어서 해결하자. (일정 산정도 마찬가지)
• 질문의 선... - 15분 규칙 (나는 혼자 고민을 너무 오래 해서, 빨리 질문하라는 피드백을 받은 적이 있는데, 15분 정도 치열하게 고민하고 질문해 봐야겠다.)

 

<협업?! 이렇게 한 번 해봐! (유동균 님)>

• 프론트엔드 개발자는 타 직군(기획자, 디자이너, 백엔드 개발자 등)과 대화를 자주, 많이 한다. 중간 다리 역할을 하자! 
• 나도 일하기 전에는 커뮤니케이션이 중요하다는 말은 많이 들었지만, 이렇게나 자주 하고 중요할 줄 몰랐다. 일하면서 커뮤니케이션이 많이 중요함을 느낀다. 제목을 보고, 어떻게 잘할 수 있는지 궁금했다. ㅎㅎ
• 맥락 - 이 사람이 뭘 모르는지 / 의도 - 이 사람이 뭘 알고 싶은지
• 맥락을 담아서, 의도를 명확하게 말하자! => 어떻게 하면 잘 챙길 수 있나?
  • 1. 목적 지향적 태도 - 감정에 치우치지 말고, 문제 해결하는 목적에 집중하기
  • 2. 광범위한 이해도 - 기획, 백엔드, 디자인 전반적으로 이해하기

 

< FE 개발 트렌드 - 리액트 개발 생태계와 Next.js까지 - 이인제(소플) 님>

• 리액트 개발 생태계
  • 상태 관리, 스타일, 데이터 fetching&caching 등으로 라이브러리를 나누고, 각각이 어떤 특징이 있는지 간단히 설명해 주신다! 
• Next.js
  
  • SSR에 최적화 -> 풀스택으로 변화
  • pages
    • 라우팅 내장
  • data fetcing
  • 최적화-이미지, 폰트 
  • api routes
    • api 코드까지 배포 가능
  • 등등

<타입스크립트로 FE 개발 레벨업 - 장기효(캡틴판교) 님>

• 타입스크립트
  • 왜 쓰나
    • 유지 보수 쉽고 생산성 높음
    • 개발자 경험(신속 / 안전)
    • 에러를 사용자보다 먼저 발견할 수 있음
  • 도입하기 어려운 이유
    • 학습 비용
    • 적용 비용(이미 자바스크립트로 잘 돌아가는 서비스를 바꿔야 하나..) => 리팩토링할 때 점진적으로 바꾸자
  • 현실적인 방법
    •  JSDoc
      • 일정 형식으로 코드에 설명 추가
      • @ts-check
  • 그런데 JSDoc보다는 타입스크립트가 편함(코드양 등)