반응형 커밋 메시지 먼저 쓰기 코드 수정 시간이 길어지다 보면 '내가 정확히 어떤 걸 수정하고 있었지?'라는 생각이 들 때가 많다. 또는 어느새 처음 의도와는 다른 코드를 수정하고 있을 수도 있다. 우연히 "커밋 메시지 주도 개발"이라고 불리는 것에 대한 글을 보고, 작은 부분부터 실천하고 있는데 효과가 꽤 좋다. 내가 이해한 핵심은 커밋 메시지를 미리 작성하는 것이었다. 내 경험상 커밋 메시지를 미리 작성하는 것은 마치 나의 자유분방한 앉은 자세를 바로잡아주는 고급 의자와 같은 역할 같았다. 무엇을 수정할지, 추가할지, 또는 개선할지 먼저 생각하고 커밋 메시지를 VS Code에 적어두면 시간이 지나도 기억해 내기 쉽고, 이미 작성해 두었던 내용이 있으니 다른 길로 새지 않는다. 따라서, 우선순위가 자연스럽게 정해지며 한가지 일에만 .. 2024. 3. 27. CRA에서 Vite로 마이그레이션: 차세대 툴로 개발 환경 개선하기 회사에서 '바쁜 기간 지나면 이건 꼭 해봐야지'했던 것 중에 하나가 바로 빌드 도구 마이그레이션 하기였다. 시간이 지남에 따라 프로젝트의 크기가 점점 커지면서, 변경 사항에 대한 소스 코드 갱신 시간이 계속해서 조금씩 증가했다. 그래서 그 잠깐 사이에 개발 흐름이 끊기는 불편함을 너무 개선시키고 싶었다. Vite를 선택한 이유 내가 현재 프로젝트에 마이그레이션할 빌드 도구로 Vite를 선택한 이유는 다음과 같다: Vite 공식문서의 Vite를 사용해야 하는 이유를 읽고 크게 공감했다. 현재 프로젝트(어드민 서비스)와 잘 맞는 SPA/CSR에 친화적인 빌드 도구이다.(SSR도 지원한다.) 공식문서가 한글 번역으로도 잘 되어 있다. 버전이 5까지 나와서 어느 정도 안정화가 되었다고 생각. 현재 프로젝트가 W.. 2024. 2. 22. "The code generator has deoptimised..."의 뜻이 무엇일까? 무슨 뜻일까? CRA로 시작한 프로젝트의 기존 번들러 Webpack을 Vite로 마이그레이션 하는 중에 "The code generator has deoptimised the styling of..."라는 로그가 보여서 무슨 의미인지 궁금했다. 찾아보니 이것은 Babel의 compact 옵션과 관련이 있었다. 이 옵션은 개행(newlines)과 공백(whitespace)을 결과 코드에서 생략할지에 대한 여부를 결정하는 데 사용되고, 이 설정 값에 따라 추가적인 공백이나 개행을 제거할 수 있다. export function setupCounter(element) { let counter = 0 const setCounter = (count) => { counter = count element.innerHT.. 2024. 2. 20. 2023, 3년 차 프론트엔드 개발자 하반기 회고 벌써 3년 차, 하반기 회고글을 쓰는 날이 오다니 그동안 참 열심히 살았나 보다. 지금 글을 쓰면서 주변을 잠시 둘러봤는데, 참 많은 것들이 변했다. 내가 맨 처음 신입 때 회고글을 썼던 그 당시에는 이렇게 선명한 4K 모니터가 없었고, 나에게 딱 맞는 키보드와 마우스, 그리고 매우 편한 의자도 없었다. 내가 몰입할 때 듣는 플레이리스트도 없었고, 차곡차곡 모아놓은 개발용 북마크와 읽기목록도 없었다. 그리고 내가 궁금할 때 질문할 수 있는 커뮤니티와 개발자 지인들도 없었다.(ChatGPT도) 그래서 이제야 조금 개발자스러운 모습이 되지 않았나 싶다. 회사 생활 이번에도 역시 회사 생활을 시작으로 글을 써야겠다. 가장 많은 시간을 보내는 곳이기도 하고, 가장 많은 고민을 하는 곳이기도 하다. 상반기도 바쁘.. 2023. 12. 30. 유연한 태도 갖기 며칠 전에 "Create / Update 시 응답에 변경된 리소스를 포함해야 할까?"라는 제목으로 글을 쓴 적이 있다. 여기서 나는 대부분의 경우에 Create나 Update 작업 시 API 응답에 변경된 리소스를 포함해야 한다는 의견이었다. 글을 쓰고 난 지 얼마 안돼서 구글 파이어베이스 시니어 개발자님의 웨비나를 듣게 되었는데, 이번에도 궁금해서 질문을 드렸다. 사실 웨비나 주제가 흥미로워서 듣게 된 거라 질문 자체에는 크게 기대를 하지 않았다. 그런데도 답변을 듣고나서, 웨비나가 끝난 다음에도 한참을 생각했다. 그래서 내가 내린 결론은 나무가 아닌 숲을 봐야한다는 것이다. 나는 사람들이 같은 말이라도 자신만의 경험에 따라 각기 다르게 받아들이고, 해석한다고 생각한다. 나는 그렇게 알아들었다. 결국 .. 2023. 12. 20. Create / Update 시 응답에 변경된 리소스를 포함해야 할까? 최근 회사에서 리액트를 사용해 어드민 서비스를 개발하면서, POST 요청의 처리 방식에 대해 생각하게 되었다. '왜 POST 요청 후에 변경된 데이터가 응답으로 오지 않을까?' 라는 의문이 든 것이다. 현재의 방식에서, 서버는 HTTP 상태 코드와 간단한 결과 메시지만을 응답한다. 예를 들어, "처리되었습니다."와 같은 메시지다. 그런데 만약 API 응답에 변경된 리소스가 포함되어 온다면 그 데이터를 즉시 사용할 수 있어서, 클라이언트는 추가적인 GET 요청을 보낼 필요가 없어진다. 또한, 별도의 데이터 리패치(refetch) 함수를 만들 필요도 없다. 그래서 좀 더 효율적이고, 깔끔하게 구현할 수 있을거라 생각했다. 다른 개발자들의 생각은 어떨까? 그래서 궁금했다. 다른 개발자들은 어떻게 구현하고 있을.. 2023. 12. 17. 타입스크립트 사용기 처음에는 무작정 사용해봤다. 그러다 실무에서 사용하기 시작하면서 정말 많은 혼란을 겪었다. 타입때문에 에러가 날 때면 짜증도 났다. 빨간 줄이 더 싫어지기 전에 VS Code의 자동완성 기능을 포기하고 타입을 any로 도배를 하다가 결국 사달이 난 것이다. 프로젝트의 복잡성이 증가하면서 매우 많은 컴포넌트가 생겨났고, 런타임에서 에러가 나면 디버깅 하기가 굉장히 힘들었다. 특히 여러 곳에서 쓰이는 프로퍼티 값을 내가 어느 데이터 타입으로 저장을 했는지 기억하기가 힘들었다. 이제는 컴포넌트든 커스텀 훅이든, 유틸 함수든 필요한 곳에 모두 무조건 타입을 제대로 정의해 준다. 이 작은 정성이 코드 레벨에서 에러를 잡아주고, 닷(.)만 입력해도 props 목록을 알려주고, 함수가 어떤 매개변수를 받고, 타입/값.. 2023. 11. 10. 이전 1 2 3 4 ··· 26 다음 반응형
