어제보다 더 나은 오늘

들어가기에 앞서Kent Beck의 Thinking About Code Review를 번역한 포스팅임을 밝힙니다. 번역에 오류가 있는 경우 댓글로 알려주시면 감사하겠습니다.   팀 워크플로우에 대해 생각해 보세요. 그런 다음 여러분의 상황에 맞는 방법을 시도해 보세요. 그런 다음 조정하세요. 엔지니어링에서 가장 흥미로운 말은 “알고 보니...”입니다.   최근 트위터에서 pull request에 대한 팀 워크플로우로 한바탕 떠들썩했을 때 제가 언급되었습니다. 코드 리뷰에 대한 또 한 번의 소모적인 논쟁에 참여하고 싶지 않았지만, 결국 이렇게 글을 쓰게 되었네요.  논의를 더 진행하기 전에, 제가 여기서 영업하려는 건 아무것도 없다는 점을 짚고 넘어가고 싶습니다. 여러분이 리뷰를 하든 안하든, 특정 git ..

새로운 에픽의 주요 요구사항 중 차트 그래프로 데이터를 시각화해서 보여줘야 하는 섹션을 구현하는 부분이 있었다. 나도 드디어 차트를 만져보게 되었다! 기존 프로젝트에서 chart.js를 이미 사용하고 있어서 추가 라이브러리 설치 없이 그대로 chart.js를 사용하기로 했다. 보통 chart.js에 대한 단점으로 주로 언급하는 게 반응형에 대한 부분인데, 이번 프로젝트는 반응형은 크게 고려하지 않고 픽셀 단위로 css를 조작하고 있는 프로젝트라 chart.js로도 요구사항을 충족할 수 있을 거라고 판단했다.  그러던 중 플러그인 관리에 있어 예상치 못한 버그를 만났다. 여러 페이지에서 각기 다른 차트 컴포넌트를 사용하고 있는 중에 새로운 페이지에서 차트 컴포넌트가 새로 추가되었고, 스토리북으로 UI 테스..

프로젝트에서 OpenAPI 스펙을 기반으로 백엔드와 API 통신에 필요한 타입 스키마와 fetcher 함수 등을 자동으로 생성해주는 orval을 사용하고 있다. 그런데 데이터 스키마 중 일부 타입이 백엔드에서 의도한 것과 다르게 내려오는 부분을 발견했다.  export type DataStatisticsUpdatedAt = string | null;export interface DataStatistics { data: DataStatisticsDataItem[]; updated_at?: DataStatisticsUpdatedAt;} 백엔드 개발자에게 `updated_at` 필드가 optional인 이유를 물어봤더니 optional이 아닌 required 필드라고 했다. 그런데 자동 생성된 타입 스키마..