Engineering Culture
구현 모양보다 동작을 지키는 테스트, 변경 전후를 비교하는 방법
내부 함수 호출 순서까지 고정한 테스트는 리팩터링마다 깨지지만 실제 오류를 놓칠 수 있다. 어떤 계약을 보호하는지 먼저 분명히 해야 한다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
DevOps
예약 작업이 겹쳐 실행될 때의 잠금, 변경 전후를 비교하는 방법
작업 시간이 실행 주기를 넘거나 인스턴스가 늘어나면 같은 예약 작업이 동시에 실행될 수 있다. 스케줄러 설정과 작업의 중복 안전성을 함께 다뤄야 한다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
AI & Data
텍스트 분류의 TF-IDF 기준선, 변경 전후를 비교하는 방법
텍스트 문제에서 복잡한 모델부터 선택하면 데이터와 평가의 기본 문제를 놓치기 쉽다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
Frontend
모달을 닫은 뒤 포커스 돌려주기, 변경 전후를 비교하는 방법
모달을 닫은 뒤 키보드 포커스가 사라지면 사용자가 작업 위치를 잃는다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
삭제 정책을 관계와 함께 정하기, 변경 전후를 비교하는 방법
부모 행을 지웠을 때 자식 행이 남을지 함께 지워질지 명확하지 않으면 데이터 관리가 어려워진다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
팀의 용어를 같은 의미로 사용하기, 변경 전후를 비교하는 방법
같은 단어를 화면, API, 데이터베이스에서 다르게 쓰면 조건을 잘못 이해하기 쉽다. 특히 상태 이름은 사용자 행동과 연결되어야 한다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.