어제보다 더 나은 오늘

들어가기에 앞서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 필드라고 했다. 그런데 자동 생성된 타입 스키마..

21년도 발표 영상이라 시간이 조금 많이 지난 영상이지만, 팀 내에서 화제의 Frontend Fundamentals로 스터디를 해보면 어떻겠냐는 얘기가 나와서 스터디하기 시작하기 전에 징검다리 같이 한 번 보면 좋을 것 같아 영상을 시청했다. 20분 남짓해서 한 번 쓱 보기에 부담없는 분량이다.  '클린코드'에 대해서 항상 클린코드란 대체 무엇인지, 각자의 정의가 다양할 뿐더러 가령 읽기 좋은 코드라고 정의할 때 어떤 코드가 A에게는 읽기 좋지만, B에게는 읽기 좋지 않을 수도 있어서 이런 부분이 어렵게 느껴졌다.   위의 영상에서는 개발자의 시간이 곧 회사의 자원이고, 이를 단축시켜줄 수 있는 코드가 클린코드라고 정의한다. 팀마다 시간을 단축시킬 수 있는 방법과 토대가 다를 것이라 우리만의 방법이 무엇..

사전 환경 및 구현 목표: - 프로젝트 내부에서 라이트/다크 모드 구분 없이 단일 모드(라이트 모드) 사용 - 시스템 설정에 따라 브라우저가 라이트 또는 다크 모드로 변경됨에 따라 파비콘 이미지가 동적으로 변경될 수 있도록 하고자 함  // app/layout.tsxexport const metadata: Metadata = { title: "Your application's title", description: "Your application's description", icons: { icon: [ { media: "(prefers-color-scheme: light)", url: "/images/favicon-light.png", typ..

개발자로 첫 발을 뗄 수 있게 해준 회사를 나왔다. 10여 년만에 다시 직장인이 되어 안정적인 소속감을 느끼며 일할 수 있었던 시간이었다. 원래는 25년 상반기 정도에 이직을 할 생각이었는데, 예상보다 조금 일찍 움직이게 되었다. 작은 규모의 팀이다보니 퇴사하기에 좋은 타이밍이 있을까 싶기는 하지만 내가 시작해놓고 결국은 마무리하지 못하고 나온 부분들도 있어서 퇴사일자가 하루 지난 지금 이 순간까지도 마음이 편치는 않다.  재작년 여름, 첫 회사 입사를 앞두고 썼던 포스팅에서 '이직의 조건 4Cs'라는 아티클을 인용하여 Compensation(보상), Collegue(동료), Chance(기회), Culture(조직 문화) 등 네 가지를 기준으로 삼으라는 내용을 언급한 적이 있다. 이번에 이직을 하면서 ..

작년 12월 무렵 한 해 동안 공부해야 할 키워드 목록을 다음과 같이 뽑았었다.  ✅ 디자인 패턴✅ TypeScript 클린 코드 ✅ Git✅ 예외 처리 및 에러 핸들링 프론트엔드의 테스트 전략 및 테스트 코드 작성 방식아키텍처✅ 렌더링 패턴: CSR, SSR 등 ✅ Next.js✅ JavaScript Deep Dive✅ 팀, 협업  공부하면서 도움이 되었던 자료들은 다음과 같다.  1. 디자인 패턴https://www.patterns.dev/ Patterns.devLearn JavaScript design and performance patterns for building more powerful web applications.www.patterns.devhttps://refactoring.guru/k..

feature flags라는 키워드를 처음 보게 된 건 트래블월렛 프론트엔드 팀에서 Trunk Based Developement(TBD) 전략을 통해 단일 브랜치를 사용하고 있다는 인터뷰 아티클이 그 시작이었다. 지속적 배포를 위한 git 전략을 연구 중에 있습니다.trunk based development라는 전략인데요 단일 브랜치로 배포 전략을 구성하는 것입니다.작업 주기를 짧게 가져 바로 메인 브랜치에 머지 되고 배포 되는 방식이어서 개발자가 부담 없이 하루에도 몇번 씩 배포할 수 있는 환경을 구축하려고 합니다.출처: https://travel-wallet.career.greetinghr.com/interview16  이게 어떻게 가능한 거지? 생각하며 조금 더 찾아보니 feature flags라는..

지난 포스팅 - 볼드, 이탤릭 등 스타일 변경 기능 구현 1편 -에 이어서 작성하는 글입니다. 1편에서처럼 데이터 스키마를 정한 이후1) 서버에서 받아온 데이터를 화면에 보여주고,2) 사용자가 입력한 스타일 정보가 포함된 텍스트를 서버에 보낼 때 정해진 양식으로 변환하는두 가지 함수가 먼저 필요했다. { trg_text: "아버지가 방에 들어가신다.", trg_text_styles: [ { range: [0, 3], styles: ['bold', 'italic'] }, ],} enum StyleToTagMap { bold = 'b', italic = 'i', underline = 'u', subscript = 'sub', superscript = 'sup',}type StyleType..

프론트엔드의 꽃은 에디터 만들기가 아닐까 싶다. 회사 제품이 CAT(Computer-Assisted Translation) tool이다보니 리치 텍스트 에디터는 아니지만 점점 그렇게 되어가고 있는...? 중이다 ㅋㅋㅋ 지난 9월 스프린트의 주요 에픽이 바로 스타일 구현이었다. 요구사항은 다음과 같았다. - 볼드, 이탤릭, 밑줄, 위첨자, 아래첨자 총 다섯 가지 스타일 제공 - 각각의 스타일을 중복으로 적용 가능해야 함 - ctrl + b 등 단축키와 스타일 버튼 두 가지 형식으로 제공 - 스타일 변경에 대해서도 실행취소/재실행 기능을 확장해서 제공해야 함 - 서버와 스타일 정보에 대한 규격을 정해 사용자가 입력한 텍스트와 함께 변경된 스타일 정보를 실시간으로 저장 이미 실시간 텍스트 편집에 대한 기능은 ..