☁️구름 김진호 스쿼드 리더 특강

  1. 설레발 주도 개발 (Hype Driven Development)
    1. 문제발생 ⇒ 발표, 자랑질, 키워드 ⇒ 빠돌이 탄생 → 실망 ⇒ 현실인식
    2. 해결책
      1. 결정하기 전에 연구하고 테스트하기
      2. 투자 대비 아주 큰 효과가 기대될 때 적용하기
      3. 경험치가 축적하다보면 기술을 선택하는데 균형잡힌 시각을 가지게 될 것.
  2. 잘 훔치고 잘 따라하기
    1. 코드리뷰, QA의 부재
    2. 업무 프로세스의 필요성 대두: 팀의 형태를 갖춰야 한다.
    3. 레퍼런스와 벤치마킹
      1. 좋은 사수나 선배가 일하는 방식을 차근차근 알려주면 좋겠지만 그건 운이 매우 몹시 좋을 때나 가능 한 일.
      2. 남들이 잘 만들어 놓은 일과 그 결과를 많이 보고 따라하는 것이 해법.
      3. 모든 것을 베끼는 것이 아니라 필요한 부분을 자신의 상황에 맞게 고치고 따라하기.
      4. 시행착오의 시간도 줄이면서, 어느정도의 성과도 기대할 수 있음.
  3. 제품처럼 팀도 애자일하게
    1. 회고
      1. 팀 회고
        1. KEEP/ PROBLEM/ TRY ⇒ 스프린트 회고를 할 때 해당 구분으로 진행하였다.
    2. 플래닝포커
      1. 회고때마다 우선순위에 맞게 다음 스프린트의 업무를 정함
      2. 매 스프린트마다 정해진 액션 아이템을 플래닝포커를 함
      3. 모든 구성원이 동의할때까지 재투표
      4. 스프린트에 정해진 포인트만큼 업루를 가져감
      5. 업무를 작게 쪼개는 연습
      6. 리뷰와 QA양도 적어짐.
    3. 정착된 업무 프로세스
      1. 1주차: 스프린트 계획 회의/ 그로스 미팅/ 디자인 및 개발
      2. 2주차: 2주차 스크럼/ 디자인 및 개발/ 코드리뷰
      3. 3주차: 코드리뷰/ QA/ 회고록/ C-Level 미팅
  4. 3줄 요약
    1. 설레발 주도 개발 멈춰!
    2. 일을 훔치고 따라하는 것부터
    3. 제품처럼 팀도 계속 개선이 필요하다.
  5. Q&A
    1. 팀 내 컨벤션은 어떻게 설정하였나요?
      1. 툴을 활용하여 최대한의 기본적인 외부 툴이 강제적으로 맞춰주는 vus외부 툴들을 활용하여 맞춰서 하도록 하자.
      2. 네이밍 컨벤션은 전사적으로 정리되어있음.
    2. 코드리뷰는 어떻게 진행하고 계실까요?
    3. 대두분의 개발자가 테스트 코드를 작성하는 편인가요?
      1. 초기 개발에는 테스트 코드 커버리지가 80% 이상이었으나 바빠지면서 테스트 코드 커버리지가 줄어듬.
      2. 인원이 많아지고 시간이 많아짐에 따라 핵심 코드 들에
      3. 테스트 코드를 위한 PR을 따로 확보하는 편: 이정표같은 역할이라고 생각하기에
        1. 모든 예외 케이스 + 리뷰 검증
        2. 수정된 프로덕션 코드가 잘못되었을 때는 절대 테스트 코드를 의심하지 말자.
    4. 개발 전에 충분한 시뮬레이션(문서화/ 기술명세서)를 통해서 준비하고 진행하자.
    5. pr을 올리기 전에 하는 행위들을 연습 중
      1. 올리기 전에 빠른 성능을 위해서 테스트 진행 후 개선 가능성 확인 중
      2. 셀프리뷰 & 셀프QA도 하는 편
    6. 구글링 하는 팁 & 공식 문서 잘보는 법
      1. 구글링
        1. 무적권 영어로 검색하는 편
        2. 깃허브 ~ 태그 / 스택오버플로우에서 찾는 편
      2. 공식문서
        1. 공식문서로 가서 해당 기능 이슈가 있는지 확인하는 편
        2. 코파일럿을 활용해서 찾기도 함.
      3. 제품을 만들면서 백엔드 개발자가 가장 중요하게 고려해야 할 점
        1. DB 모델링을 효율적으로 할 수 있는지.
        2. API 성능 관련된 부분
        3. 예시: 댓글 + 이모지 불러오는 기능이 느리다 (CPU 부하가 생긴다. + indexing 전략)
    7. 신입 개발자에게 중요하다고 생각하는 역량 ⇒ 소프트 스킬 (커뮤니케이션)
    8. 백엔드 ~ 프런트엔드 개발자들은 서로 개발 파트에 대한 얕은 지식은 가지고 있어야 한다.
    9. 회의 전 효율적은 소통을 위해서 그라운드 룰을 설정하고 들어간다.
      1. 말 끊지 않기.
      2. 그 자리에서는 피드백을 정리 한 후 반박하지 않는다. ⇒ 다음 스프린트때 생각하고 말하는 방법을 채택하고 있다.
    10. 취준에 대한 조언
      1. 깃허브 PR 커밋 메세지는 신경써서 하도록 하자.
        1. 커밋 링크를 이력서에 활용할 정도로 해보자.
      2. 회사의 기술 스택에 맞춰서 준비할 필요가 있다.
    11. 깃허브 상의 최대한 봉일러 플레이트 코드들을 확인하는 편.
      1. 중요한 것은 시작을 하는 편
      2. 입사 당시 코드 작성할때 주어진 업무에 대한 유사한 레퍼런스를 확인하여 체득하는 경험이 주요하게 작용했다. ⇒ 사용하고나서도 꼭 기억하려고 하는 편이다.

👓 스타트업 코드 특강: 개발자의 이해 (연시완 대표)

  1. 포트폴리오 작성 팁

    1. 기능을 왜 구현했는지, 어떤 문제가 있었고 어떻게 해결했는지에 대해서 작성해야한다.

  2. 자기소개글 작성

    1. 나는 무슨 개발자일까? (한줄 요약)
    2. 나는 왜 국제통상학을 졸업하고 백엔드 개발자가 되고 싶을까? (세줄 요약)
      1. 개발이 재밌어서
        1. 왜 재밌는가?
          1. 뭐 만들고 싶으면 생각 잘해서 필요한거 찾아서 공부하고 적용해볼 수 있고
          2. 막상 실전되면 에러 시상 많이 뜨고 맘대로 안되서 또 공부하고 찾아보고
          3. 적용되면 세상 신나서 보람차니까
          4. 그리고 보면 또 개선될 여지가 있어서 이 과정을 또 할 수 있으니까
          5. 심지어 성능이나 구조가 바로바로 개선되는 것이 보이니
      2. 성능개선하는 과정이 보람차고 재밌어서
      3. 근데 이러면 면접관 입장에서는 노잼

  3. 뭘 잘할 수 있어서 개발자가 된걸까

  4. 🏓개발자란

  5. 👣프로젝트 진행 방법

  6. 💽git & github