꾸준히 하나씩

1. 개요 - git 작업을 하면서, rebase를 안써본 것은 아니다. - "PR시 merge와는 다르게 브랜치 내역이 남지 않아, 커밋 내역을 깔끔하게 관리할 수 있다."라는 장점이 있는 것만으로 "느낌"만 가지고 있었다. - 그러다 보니, 협업하면서 소위 "어버버" 대는 경우가 생겨, 이번 기회에 merge, rebase를 좀 비교해보았다. 2. branch를 병합시키는 기본, merge - merge는 말 그대로 branch를 병합시키는 것이다. - merge는 두 가지 종류가 있는데, 다음 예시 상황을 기준으로 설명해보겠다. > 기본: main 브랜치, main의 커밋1에서 checkout한 dev 브랜치가 있다. dev -> main으로 병합시킨다. > 상황1: main 브랜치에서 별다른 co..

1. 개요 - 팀 프로젝트를 최소 3회 이상 해오면서, git 관련해서 기본적인 것들은 많이 해봤다고 자부했다. - 최근 사야매 프로젝트를 시작하면서, 처음으로 커밋 내역, 이슈 내역 등을 꼼꼼하게 관리하기로 룰을 짜고 작업을 하고 있다. - 그런데, 필자가 생각보다 git을 자유자재로 사용하지 못하고 있음을 느꼈다. - 특히, 브랜치를 이동하면서 하는 작업에서 아직 많이 미숙하다고 느꼈다. - 그래서 사야매 프로젝트를 하면서 git 관련해서도 좀 더 성숙해지고자 한다. - 종종 이렇게 git 관련된 글들을 적을 일이 많을 것 같다. - 참고로 작성되는 글들은 특정한 목차를 가지진 않다. - TIL 느낌으로 적을 예정이고, 경험적으로 잘 몰랐던 것들, 새로 알게 된 내용, 알고 있었지만 다시 정리한 내용..

개요 - 사야매 프로젝트를 하면서, git 협업 중 CRLF 이슈가 발생했다. - lint 설정을 이용해서 CRLF -> LF로 변경해서 이슈는 해결했지만, LF로 변경하면 변경이 발생한 파일은 모두 커밋이 되는 불상사가 발생한다. - 이에, CRLF/LF 이슈는 git 협업을 본격적으로 시작하기 전에 세팅해두어야 할 이슈인 듯 하여 이렇게 블로그로 정리하게 됐다. 문제원인: OS가 채택하는 기본 개행문자의 차이 - Window는 기본적으로 CRLF로 라인을 끝내고, Mac, Linux는 LF로 끝낸다고 합니다. - 그래서 개발 협업에서 lint와 prettier를 쓰는 경우, 이 개행문자 차이가 에러로 인식될 수 있는 것입니다. 문제 해결 방법: git config & IDE setting 1) git..

1. 개요 - 사야매 프로젝트 기본 세팅을 진행하면서, nvm을 사용하기로 했다. - nvm을 사용하기로 한 이유는 다음과 같다. => node.js 버전을 v20.2.0 채택했다. es2023에서 제공하는 문법들도 경험할 수 있으리라 판단했기 때문이다. => 어플리케이션이 의존하고 있는 node.js 실행환경은 docker로 맞출 수 있다. => 하지만 로컬 node.js 환경 자체는 docker로 맞출 수 없다. => 로컬에서 작업을 할 때, ide 자체는 로컬 환경에 기반하므로, 코드 자동완성이나 패키지 설치에서 버전 이슈가 발생할 수 있다. => node.js 버전 매니저인 nvm을 이용하면, 로컬에서 사용하는 node.js 버전을 간편하게 맞출 수 있어, 사용하기로 했다. 2. nvm에 대한 간..

평소에 야구를 즐겨합니다. 대학시절부터 지금까지 약 8년동안 쭉 야구를 하고 있는데요. 야구 짬밥이 늘어나보니, 주변 지인들이 팀에서 감독직을 수행하는 것을 많이 볼 수 있었습니다. (팀에서 감독은 보통 1년에 한번씩 바뀝니다. 물론 저는 감독을...해보진 않았어요.) 그 지인들이 감독직을 수행하면서 공통적으로 이야기하는 애로사항이 있었습니다. 아 라인업 짜기 귀찮다. 야구팀 감독이 라인업 짜는 프로세스는 대략 이렇습니다. 1. 경기 투표를 올립니다.(보통 카톡, 라인, 밴드 같은 그룹 메신저를 많이 이용합니다.) 2. 투표가 종료되면, 참가자 명단을 확인합니다. 3. 참가자 명단을 보고 타순을 직접 타이핑해서 짭니다.(엑셀이나 메모장 혹은 메신저 내 "나에게 채팅하기" 같은 채널을 이용합니다.) 사람에..

1. 문제상황 - carryduo 프로젝트에서 리팩토링 할 내용이 있어, 간만에 프로젝트를 켰다. - 리팩토링 할 것은 계층 분리, 테스트 코드와 관련된 것이었는데, 코드의 printWidth가 너무 넓게 설정되어 있는 것이 거슬려서, .prettierrc 파일에서 printWidth를 줄였다. - 그런데, 다음과 같은 에러가 발생했다. error Replace `↹` with `··` ↹는 tab, 줄바꿈을 의미한다. ··는 스페이스바, 띄어쓰기를 의미한다. - 기존의 eslint 설정과 prettier 설정은 다음과 같았다. 1) eslint module.exports = { parser: '@typescript-eslint/parser', parserOptions: { project: 'tsconf..

1. 개념 - docker compose는 docker에서 사용하고자 하는 이미지를 바탕으로 컨테이너를 실행할 때, 컨테이너 실행 맥락에서 필요한 명령어를 작성한 yml 파일이다. - docker compose를 이용하면, 복수의 컨테이너를 편리하게 생성 및 실행할 수 있다. 2. Docker compose의 이득 - docker compose의 가장 큰 이득은 복수의 컨테이너를 생성하고, 컨테이너 간 네트워크 연결을 docker-compose 한 파일 안에서 일괄적으로 처리할 수 있다는 것이다. - 예컨대, 다음과 같은 상황에서 docker compose는 컨테이너를 실행하는 데 큰 이점을 가진다. 예시상황: 웹 어플리케이션을 실행하는 이미지와 DB 이미지를 각각 컨테이너로 실행시키고, 두 컨테이너를 ..

1. 도커의 필요성 - 한 운영체제에서 어플리케이션을 실행하기 위해서는 여러 기반 소프트웨어들을 설치해야한다. 예컨대, Node.js, DB 등 말이다. - 이 떄, 기반 소프트웨어들(실행 환경)은 운영체제마다 실행되는 맥락이 달라, 설치하는 데 번거로움이 존재할 수 있다. - 도커는 다른 OS를 가진 호스트(어플리케이션을 실행할 머신)들 간에 실행 환경을 편리하게 설치하고 사용하기 위한 니즈에서 탄생한 서비스다. - 요약해서, 도커는 어플리케이션을 실행하는 데 필요한 모든 실행환경을 하나의 묶음, 패키지로 묶을 수 있는 서비스이다. - 도커를 통해, 여러 OS에 어플리케이션을 안정적으로 배포하고 실행할 수 있는 이득을 취할 수 있다. 2. 기반 - 컨테이너 기술은 근본적으로 리눅스 운영체제의 기술이다...

0. 개요 - 최근 들어, 아키텍처와 관련된 글들을 꽤 작성했다. - 이 글은 그러한 글들의 발단이 된 리팩토링 작업에 대한 글이다. 아키택처 글들은 리팩토링 작업을 하면서 해당 작업의 배경 지식들을 공부한 내용이었다. - 리팩토링한 내용은 아직 100% 만족하진 않는다. 공부를 하는 과정에서, "아, 이건 이런 식으로 하는 게 더 좋았을 수도 있겠다."하는 생각들이 많이 들었기 떄문이다. - 일단, 이 글은 작업된 내용을 기반으로 한다. 중간중간 작업된 내용 중 개선점에 대해서도 서술해보겠다. 많이 부족한 글이기 때문에, 잘못된 내용에 대한 피드백 혹은 격려 주시면 정말 감사하겠습니다. 1. Carryduo 백엔드의 계층 구조와 기존 코드의 문제점 1) Carryduo의 백엔드 계층 구조 - Carry..

1. 다시 보는 계층형 아키텍처 - 계층형 아키텍처는 소프트웨어를 구성하는 소스코드를 관심사에 따라 "계층"으로 분류한 구조이다. - 계층형 아키텍처의 최대 관심사는 "관심사에 따른 계층 분리"이며, 일반적으로 다음과 같은 구조들이 제시된다. presentation -> business(service / domain) -> data access(persistence) -> db - 이러한 계층형 아키텍처는 다음과 같은 장점을 가진다. 계층별 관심사가 분리되기 때문에, 코드가독성과 유지보수성이 높다. 모듈 교체가 용이하다. 예컨대, business 레이어에서만 사용하는 모듈을 교체할 때, 이에 따라 다른 계층에 미칠 사이드 이펙트가 현저히 적을 것이다. 테스트가 용이하다. 각 계층은 관심사에 따라 분리되어..