1주차 멘토링

멘토링

백로그

• 이런 식으로 관리하면 베스트이긴 합니다.
• 우선순위, 사이즈 같은 것도 정리되어 있구요.
• 실제 팀마다 조금씩은 다른데 PO가 다들 해줍니다.
  • 개발자들이 이렇게까지 상세하게 하지는 잘 하지 않습니다.
  • 설정 방법이 충분히 적당하고도 남습니다.
• 작성하실 때, 이 사람들이 현재 뭐하고 있는지 파악할 수 있을 정도면 충족되면 잘 정리한 거에요.

마일스톤 관리

• 마일스톤이 적절한 범위로 되어있는지 말씀드리고 싶었음
• 현업에서는 JIRA 사용
• 방향성은 맞음
  • 하는 이유는 팀원들이 빠르게 하는 것, 언제 완료되는지 등의 커뮤니케이션 비용 줄이기 위해 사용
  • 이것만 맞으면 더 추가해도 괜찮음
  • 커뮤니케이션 비용이 더 낮으면 차라리 커뮤니케이션을 직접 하는 게 더 나을 수 있음
• slack에 남기면 history 관리 되기 때문에 좋음

task 사이즈, 시간 등 정하는 방법

• 사이즈는 개발자가 얘기함
• 중요도는 기획자, PO, 이끌고 있는 리더가 정함
  • 근거는 팀원들이 이야기함
• 회의를 통해서 백로그의 우선도를 정합니다.
  • 다만, 오너가 더 우선 순위가 높다고 하는 것은 더 먼저 하게 되어 있음.
• 회사에서 내가 해야 할 일은 * 1.5로 시간을 책정해서 이야기함.
  • 따로 태클이 가끔 들어와서 일을 잠깐 미룰 수도 있기 때문. (다른 일을 하느라)

3306 포트를 열지 않고 DB 관리하기

• 외부에서 접근하지 못하도록 하기 위해 포트를 개방하지 않음.
• 현업에서는 IP 자체를 모릅니다. 보안, VPN, 서버 등을 거쳐서 들어갑니다.
  • DB 서버는 내부에서만 접근 가능합니다.
  • VPN 같은 것도 달아요.
  • 내부망을 구축하면 쉽게 해결할 수 있습니다.
  • DB를 직접 접근해서 확인할 때는 어떻게 하나요?
    • VPN으로 보통 접근합니다.
    • 누가 접근했는지 기록하기 위해 VPN을 사용합니다.
      • A,B라는 특정 인물을 제외하고는 못 들어가도록 막음.
  • 그 외의 해결책?
    • 공부용으로 장단점을 보는 건 나쁘지 않아요.
  • 인프라 쪽에서 보안 팀이 따로 있어요.
    • 의도하지 않은 아이피에서 접근하면, 작업 요청이 이상하면, ⇒ 감지 센터에서 확인합니다.
    • 인프라 팀 내부에 보안 부서가 따로 있긴 합니다. (현업 기준)
• SSH 터널링은 잘 사용하지 않을 것 같습니다. (보안 이슈가 있을 것 같습니다.)
• VPN을 사용하는 이유는 인증된 사람을 필터링 하기 위해
• 아마존은 특정 IP로만 접근할 수 있도록 (whitelist) 설정할 수 있음.
  • 가장 비용이 적고 현재 상황에서 쉽게 구현할 수 있음.
  • ncp도 있는지는 모름, 찾아 봐야 함.
• 보안에서 가장 중요한 것은 any ip를 허용하지 않는 것
• 둘째로는 key를 절대 올리지 않는 것(config 올리면 안돼요)
  • private repo라면 올릴 수도 있지만 좋지는 않음.
  • 차라리 slack으로 주고 받는 게 나을 수도 있음. (현재는 노션을 사용하고 있는데, 이것도 괜찮은 방법이긴 합니다.)

페어 프로그래밍

• 해보면 매우 좋습니다.
  • 현업에서도 간혹 합니다.
• 현업에서는 혼자 보면 실수하는 곳에서 사용합니다.
  • 코딩을 오래해서 머리에 잘 안 들어가는 경우
  • 머리 잘 돌아가는데 옆에서 훈수 들어오면 안 좋다고…
  • 주니어가 시니어의 코드 스타일을 보기 위해 사용하기도 함
• 페어 프로그래밍의 장점은 혼자 했을 때의 부담, 머리가 잘 안 돌아가는 컨디션 등을 극복할 수 있음.
• 코드 리뷰를 통해 균등하게 유지할 수 있음
  • 두 명이서 하나만 잡고 있으면 시간이 더 걸림
  • 이러한 이유로 하는거면 조금 줄일 필요가 잇음
• 핵심 작업도 잘 생각해보고 하기
  • 이거는 해보면 좋음

판단 능력이 떨어졌을때는 도움 되긴 함

• 조금 더 머리가 돌아가긴 함

• 오류가 덜 나는 근거는 다른 방법도 있음

  • 테스트
  • 코드 리뷰
  • E2E 테스트

  ⇒ 모든 테스트의 마무리는 End to End 테스트임.

• 제대로 된 오류를 잡기 위해서 페어프로그래밍 하는것은 조금 어려움

• 두 명이라고 오류가 덜 나는 것은 아님

  • 차라리 기계를 믿는 것이 나을 수 있음.
  • 한 명은 테스트 코드, 한 명은 main 코드 작성하는 방법도 있을 수 있음.

⇒ 어떻게 하면 우리가 오류를 줄일 수 있을까? 에 대해 고민해야 합니다.

페어 프로그래밍을 피해야 하는 경우

• 누가 봐도 각자 코딩하는 게 빠르다고 예측될 때
• 핵심만 각자 잘 이해하고 같은 목표가 설정되었다면 각자 코딩하는 게 빨라질 가능성이 높음.

마감 기한과 페어 프로그래밍의 관계

1. 코드 리뷰
2. 테스트 코드 작성
3. E2E 테스트

⇒ 이 녀석들도 비슷한 맥락에 적용됩니다. 테스트, 검증, 리뷰 이런 내용은 4번 질문에 똑같이 해당 사항이 됩니다.

멘토의 경험 공유)

• 고객과의 약속은 정말 크다. 신뢰는 한 번 깨지면 복구 불가
• 버그, 이상 현상이 있어도 마감 일자는 맞춰서 내야 함.
• 그럼에도 불구하고 치명적인 에러가 발생하면 안된다.
• 결제가 들어가면 개발자는 매우 보수적, 겁을 먹게, 공포 ⇒ 돈 관련은…
• 자잘한 버그는 감수하고 일단 완성하는 것이 맞음.
  • 심지어 게임은 수정할 수 없는 버그도 있음.
• 버그 관리하는 것이 개발자의 능력에 따라 달라진다?
  • 개발자는 코드를 짜지 않고 문제를 해결하는 것이 가장 좋음
    • https://youtu.be/3H4umWD5bwI?si=jVzAhCpiXmIFt4jv

E2E 테스트 환경 세팅에서 DB를 만들어야 하는가?

• 현업에서는 DB 모킹은 하지 않음.

• 개발 서버/스테이징 서버/하나뭐였지, 프로덕션?

• 6주 동안 완성해야 하는데, 스테이징 서버를 사용하면 테스트 DB를 구축해야 합니다.

  • 시간 대비 완성이 가능하다면 테스트 DB를 만들고
  • 안되면 모킹을 활용하세요.

• 모킹을 했다가도 사용자가 테스트 했을 때, 문제가 발생함

  • 모킹은 이렇게 되겠거니 하고 예측하는 것이기 때문

• 스테이징 서버는 실 서버의 DB를 하루 전에 업데이트 해주는 형식

  ⇒ 결국 시간, 돈, 인력 비용이 많이 나가게 됨. 돈을 잘 버는 어느 정도 큰 서비스의 경우에는 사용이 좋음.

• 우리 프로젝트는 그냥 모킹하는 게 나을 수도 있음.

에러는 우리와 함께 숨쉬면서 살아가는…

• 어떻게 해결할 지, 다음에 이 에러가 일어나지 않도록 방지하려면 어떻게 프로세스를 보완해야 하는지… 이런 걸 고민하면서 살아갑니다.

스프린트 리뷰, 스프린트 플랜 탬플릿 조언

• 이전 스프린트 요약은 리뷰나 회고 시간에 정리할 테니 빼도 될 것 같습니다.
  • 스크럼을 진행하기 때문에 빼도 됨
• 지금 작성한 정도에서 충분합니다. 추가할 내용도 딱히 없을 것 같아요.

개별 멘토링은 이번 주 토요일이 될 것 같습니다.

• 일요일 저녁에 개별적으로 진행합니다.