본문 바로가기
카테고리 없음

[우아한테크][3월] "개발자 원칙" : 제어할 수 없는 것에 의존하지 않기

by 푸고배 2023. 4. 16.

신청 배경

평소에는 잘 확인하지 않는 개인 메일에 [신청 시작] 3월 세미나 | 테크 리더 3인이 전하는 "개발자 원칙" 이라는 제목이 눈에 띄어 들어가게 됐다.

'3월 29일이면 오늘이구먼' 하고 넘어가려다가 눈에 띄인 주요 내용추천 대상이 요새 내가 하고 있는 고민과 비슷한 것 같아서 바로 신청해버렸다. 

강연 내용

그 중 첫 번째 세션인 인프랩의 이동욱님의 제어할 수 없는 것에 의존하지 않기 라는 강연을 정리해보려 한다.

 

프로덕트 엔지니어란?

일정은 지키지만 버그가 많은 개발자 VS 일정은 못 지키지만 버그가 없는 개발자

 

두 가지 중 어떤 개발자가 되는 것이 좋을까?

 

나카지마 사토시의 '오늘, 또 일을 미루고 말았다.' 라는 책에서는 아래와 같은 말이 나온다.

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

 

Window95의 마우스 더블클릭, 우클릭을 만든 슈퍼 개발자라고 할 지라도 100점짜리 프로그램을 원하지는 않는다.

 

연구원이 아닌 프로덕트 엔지니어인 우리는 고객이 원하는 기능고객이 원하는 시점에 전달하는 것이 중요하다.

 

이 말이 일정 >> 퀄리티를 뜻하는 것은 아니다.

아무리 급해도 항상 80~90점짜리 소프트웨어를 일정 내 개발할 수 있는 방법이 필요하다.

 

일정을 항상 잘 지키는 사람들의 공통점

가장 좋은 코드를 선택하는 방법으로, 본인만의 기준과 원칙을 바탕으로 빠르게 결정한다.

선택의 순간마다 고민하는 사람보다는 원칙에 따라 빠르게 결정하고 중요한 것만 고민하는 사람을 좋은 개발자라고 정의할 수 있을 것 같다.

 

제어할 수 없는 것에 의존하지 않기

현실세계에 있는 문제를 가장 실용적으로 풀 수 있는 여러 가지 방법들을 다루는 실용주의 프로그래머라는 책에는 아래와 같은 말이 나온다.

현실 세계의 변화와 설계 사이의 결합도를 줄여야 한다.
자신의 힘으로 제어할 수 없는 속성에 의존하지 말라.

 

예를 들어서, 2014년부터 개인정보를 무분별하게 사용하는 것을 금지하는 법이 생겼다.

절대 변하지 않을 것이라 믿고 의존했던 속성이었지만, (외부적인 요인의) 변경이 발생하여 대부분의 시스템에 주요키 변경이 필요해졌다.

이후로 외부에서 전달 받은 값은 절대 주요키로 선택하지 않아야겠다라는 교훈을 얻었다. (ex. 내부적인 해시값을 이용하는 방법?)

 

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

 

제어할 수 없는 코드 vs 제어할 수 있는 코드

제어할 수 없는 코드

아래 코드는 '일요일이면 할인'해주는 코드이다.

 

export class Order {
  private _amout: number;
  discount() {
    const new = LocalDateTime.now();
      if (now.dayOfWeek() === DayOfWeek.SUNDAY) {
      this._amount = this._amout * 0.9;
    }
  }
}

 

const new = LocalDateTime.now()는 시간에 종속되는 코드이다.

따라서 아래 테스트 코드는 '일요일에만 성공하는 테스트'이다.

 

if('일요일에는 주문 금액이 10% 할인된다', () => {
  const sut = new Order(10000);
  sut.discount();
  expect(sut.amout).toBe(9000);
});

 

하지만, 아래와 같이 mock데이터를 이용하면 실행하는 날짜에 영향을 받지 않고 항상 같은 결과를 반환하는 테스트 코드를 작성할 수 있다.

 

if('일요일에는 주문 금액이 10% 할인된다', () => {
  jest.mock('@js-joda/core');
  LocalDateTime.now = jest
    .fn()
    .mockReturnValue(LocalDateTime.of(2023, 3, 26));
  const sut = new Order(10000);
  sut.discount();
  expect(sut.amout).toBe(9000);
});

 

완전히 해결됐다고 볼 수 있을까?

 

날짜 라이브러리(js-joda)가 교체된다면?
테스트 프레임워크(jest)가 교체된다면?

 

위의 코드는 제어할 수 없는 코드라고 할 수 있겠다.

 

제어할 수 있는 코드

위 코드에서 now에 해당하는 시간값을 파라메타로 받는 코드로 변경한다.

export class Order {
  private _amount: number;
  discount(now = LocalDateTime.now()) {
    if (now.dayOfWeek() === DayOfWeek.SUNDAY) {
      this._amount = this._amout * 0.9;
    }
  }
}

테스트 코드도 아래와 같이 변경할 수 있다. 

if('일요일에는 주문 금액이 10% 할인된다', () => {
  const sut = new Order(10000);
  sut.discount(LocalDateTime.of(2023, 3, 26));
  expect(sut.amout).toBe(9000);
});

이 코드는 mocking이 필요없지만, 선택한 날짜가 일요일인지 확인이 가능하다.

파라미터를 넣어주지 않아도 디폴트 값으로 현재 시간을 받기 때문에 정상적으로 코드가 동작하게 된다.

 

제어할 수 없는 함수에 의존하는 모든 코드가 제어할 수 없는 코드가 되기 때문에 유의해야한다.

제어할 수 없는 코드란 순수하지 않은 함수 혹은 객체를 말한다.

회사 레벨에서 제어할 수 있는 것과 제어할 수 없는 것?

제어할 수 없는 것  제어할 수 있는
우리 회사의 매출
우리 회사의 투자
높은 개발자 연봉
스타트업 전체의 권고사직
팀원의 성장환경 🎉
좋은 시니어 개발자 채용 사내 강연
- 좋은 시니어들의 노하우를 흡수
정기적인 외부 시니어 강연
- 필요한 노하우를 먼저 제시하는 팀원들
잦은 피드백
을 줄 수 있는 환경
- 정적분석, 테스트 코드, Lint(코드포맷팅)

 

Reference


 

반응형

댓글