Engineering Culture
리뷰할 수 있는 크기로 변경 나누기, 변경 전후를 비교하는 방법
기능 추가와 이름 변경, 포맷 수정이 한 번에 섞이면 리뷰어가 실제 동작 변화를 찾기 어렵다. 변경을 나누는 기준은 파일 수보다 설명 가능한 목적이다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
DevOps
생존 확인과 준비 상태를 나누는 헬스 체크, 변경 전후를 비교하는 방법
프로세스가 떠 있다는 사실과 요청을 처리할 준비가 됐다는 사실은 다르다. 데이터베이스 연결이 잠시 끊겼을 때 프로세스를 계속 재시작하면 복구를 더 어렵게 만들 수 있다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
트랜잭션의 경계를 정하는 법, 변경 전후를 비교하는 방법
서로 연결된 두 번의 저장 중 하나만 성공하면 데이터의 의미가 깨질 수 있다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
ETag로 같은 응답 다시 확인하기, 실패를 설명할 단서 남기기
변경되지 않은 자원을 매번 전체로 내려받으면 불필요한 전송이 생긴다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Frontend
브라우저 저장값의 버전 관리, 실패를 설명할 단서 남기기
로컬 저장소의 데이터 모양을 바꾼 뒤 예전 값 때문에 화면 초기화가 실패할 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
아키텍처 결정에 당시의 맥락 남기기, 변경 전후를 비교하는 방법
결론만 남은 설계 문서는 시간이 지나면 왜 그런 선택을 했는지 설명하지 못한다. 제약이 달라졌을 때 바꿀 부분과 지킬 부분을 구분할 수 있어야 한다. 같은 조건에서 얻은 증거를 중심으로 작은 예제와 확인 기준을 정리합니다.