우아한 테크세미나 정리

wonseok·2023년 3월 29일
0

이동욱(인프랩 CTO)

1. 일정은 지키지만 버그가 많은 것
2. 일정은 못 지키지만 버그가 없는 것

프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을
기한 내에 완성하는 일이다.

일정 > 퀄리티

일정을 항상 잘 지키는 분들의 공통점?

가장 좋은 코드를 선택하는 방법은?

-> 실수가 자주 나오는 부분은 10점, 20점 감점 감안하다.
-> 나머지 부분은 본인만의 기준과 원칙으로 빠르게 결정

원칙에 따라 빠르게 결정하고 중요한 부분만 고민하는 개발자.

원칙 : 제어할 수 없는 것에 의존하지 않기!

현실 세계의 변화와 설계 사이의 결합도를 줄여야 한다.
전화번호를 식별자로 사용하는가?
자신의 힘으로 제어할 수 없는 속성에 의존하지 말라 - 실용주의 프로그래머 중

외부에서 전달 받은 값은 절대 주요키로 선택하지 않는다.

제어할 수 없는 것에 의존할 수록
변화에 쉽게 흔들리는
소프트웨어가 만들어진다.

제어할 수 없는 코드?

날짜 라이브러리 (js-joda)가 교체가 된다면?
테스트 프레임워크 (jest)가 교체가 된다면?
변화에 쉽게 흔들리는 소프트웨어

제어할 수 있는 코드?

Default Prameter로 제어할 수 없는 값을 주입 받는다.

전염되는 제어할 수 없는 코드

여러 강의들 중 결제 금액 계산 결과가 100원이 넘는 건들만 골라서 PG 결제

제어할 수 없는 것 : 외부 서비스 Modal
제어할 수 있는 것 : 결제 금액 계산, 100원 이상 걸러내기 (전부 단위테스트로 코드를 짤 수 있음)

제어할 수 없는 코드와 제어할 수 있는 코드를 분리하라.

제어할 수 없는 코드란 순수하지 않은 함수 혹은 객체


제어할 수 없는 팀원?

세상에 좋은 개발자들이 많은데 모셔오는 것? <- 제어할 수 없는 영역
그렇다면 우리 팀으로 모셔오지는 못하더라도 저 사람이 가진 노하우를 흡수하자. <- 제어할 수 있는 영역
좋은 시니어 개발자 사내 강연
좋은 시니어들의 노하우를 흡수

정기적인 외부 시니어 강연
필요한 노하우를 먼저 제시하는 팀원들

잦은 피드백을 줄 수 있는 환경
스타트업에서 좋은 코드리뷰를 하기가 쉽지 않다.

코드를 한 줄이라도 짜면 정적분석 돌아가고, 테스트 코드를 대부분 짜고 있는데,
테스트가 실패하면 배포를 못하도록, Lint로 최소한의 규칙 만드는중

장소를 옮겨 가면서 홈경기를 치르면 원정경기에 강해질 것이다.
다른 곳에서 시합할 때의
산만함과 혼란스러움에 익숙할 테니까 - 88연승의 비밀 중

되는 일만 하는 조직은 없다.
스타트업은 안되는 일만 하니깐 스타트업이다.
이런 부분이 중요하다.

안좋은 환경에서도 좋은 환경을 찾아내는 것이 중요하다.
이번 사건으로 인해서 나는 운을 축적했구나.

제어할 수 없는 것에 거리두기
제어할 수 있는 것에 집중하기

박미정 (무신사 개발실장)

실패가 뭘까요?

일을 잘못하여 뜻한 대로 되지 아니하거나 그르침
새벽 5시에 일어나서 미라클 모닝 하려고 했는데 눈뜨니 아침 9시
PM한테 내일까지 기능 개발 완료라고 했는데 불가능을 인지함
성장하고 싶은데 마음과 다르게 멈춰있는 상태

그래서 오늘의 이야기는.

나, 이런 실패들을 해봤지.

개발자로서 나의 실패

  • 버그 있는 코드 배포
    -> 사용자가 서비스 이용 시 문제 발생 -> 코드 리뷰 절차 강화 > 테스트 코드 작성 문화
  • 운영 DB 테이블 삭제
    -> 데이터 복구 밤샘 작업에도 불구하고 손실된 데이터
  • 코드 배포 후, 성능 문제 발생
    -> 서버 다운으로 서비스 중단 -> 성능 테스트 절차 강화 > 고급 API 로직 분석
  • 언제나 기시감이 드는 코드 작성
    -> 나만 성장하지 않는 것 같은 자괴감

제품 만드는 사람으로서 나의 실패

  • 나는 개발자니까 기술에만 집중하는 태도
    - 코드는 미미하게 견고해졌지만, 서비스를 떠나가는 사용자
  • 개발 문화만 너무 소중한 태도

관리자로서 나의 실패

  • 팀의 역량을 파악하기 전 일을 계획함
    - 프로젝트 중단
  • 개발팀 과잉보호
    - 소통과 신뢰가 어려운 개발팀
  • 팀원을 이해하기 전, 판단
    - 어려운 리더가 됨

실패를 대하는 법

TDD에서 RED는 실패를 전제로 테스트 코드를 작성한다.
Agile에서도 빠르게 실패를 하는 것을 권장한다.

실패하지 않았다는 말은 시도하지 않았다는 말이죠.
실패한 적이 없는 사람은 늘 회피하는 사람일 거에요.
그리고 그 실패 앞에서는 누구나 가라앉는 감정에 빠집니다.

삶에서 너무나 당연한 실패인데 스스로에게는 참 인색하다.
나 자신에게 실패해도 괜찮다고 당연하다고 해줘라.
모든 실패는 나름의 의미가 있지만 모두 극복할 필요는 없다.
나만의 실패를 대하는 루틴도 꼭 만들어라.

박성철 (마켓컬리 시니어 리드 개발자)


  • 강연자님이 배민 입사 처음했을 때 옆자리에 붙어 있던 문구
    평생 직장은 없다.
    최고가 되어 떠나라!

0개의 댓글