Engineering Culture
리뷰 의견의 강도를 분명히 표현하기, 실패를 설명할 단서 남기기
수정이 필수인 결함과 개인적인 취향이 같은 어조로 전달되면 작성자가 우선순위를 판단하기 어렵다. 의견의 이유와 강도를 함께 적어야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
Frontend
입력 필드에 이름 붙이기, 실패를 설명할 단서 남기기
플레이스홀더만 있는 입력창은 값을 입력한 뒤 어떤 항목이었는지 알기 어렵다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Frontend
버튼과 링크의 역할 나누기, 실패를 설명할 단서 남기기
클릭할 수 있는 글자를 모두 div로 만들면 키보드 조작과 브라우저의 기본 동작을 따로 구현하게 된다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
리뷰할 수 있는 크기로 변경 나누기, 실패를 설명할 단서 남기기
기능 추가와 이름 변경, 포맷 수정이 한 번에 섞이면 리뷰어가 실제 동작 변화를 찾기 어렵다. 변경을 나누는 기준은 파일 수보다 설명 가능한 목적이다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
AI & Data
전처리에서 생기는 데이터 누수, 실패를 설명할 단서 남기기
모델에 평가 데이터를 직접 넣지 않았어도 전처리 단계에서 평가 정보가 전달될 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
생존 확인과 준비 상태를 나누는 헬스 체크, 실패를 설명할 단서 남기기
프로세스가 떠 있다는 사실과 요청을 처리할 준비가 됐다는 사실은 다르다. 데이터베이스 연결이 잠시 끊겼을 때 프로세스를 계속 재시작하면 복구를 더 어렵게 만들 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.