개발 블로그

최근에 사이드 프로젝트를 개발하려고 하는 순간..!몇달 되지도 않았지만 쌓여있는 레거시 코드들을 보면서 뭐가 이렇게 급해서 모든 기능들이 한 파일안에 전부 들어가 있는지..가독성도 떨어지고 기능 하나 수정하려고 스크롤을 위 아래로 왔다 갔다 하다가 깨달았다.이거 분리해야겠다고..그래서 한 파일에 몰려있던 UI, 로직, API 호출을 쪼개고, Custom Hook으로 분리하고, 유틸 함수로 빼냈다.나름 뿌듯했다.그런데 피드백을 받고 깨달았다.나는 "관심사 분리"를 너무 좁게 생각하고 있었다.내가 한 건 "함수 단위 분리"였다. 사이드 이펙트 줄이기, 재사용성 높이기, 코드 정리하기. 틀린 건 아니지만, 관심사 분리의 일부분일 뿐이었다.알고 보니 관심사 분리는 어떤 관점에서 바라보느냐에 따라 완전히 다른 이..

디자이너 없이 개발을 하려고할때 주로 UI 라이브러리를 써볼까? 하는 생각이 든다.그래서 이런 저런 UI 라이브러리를 사용하다보면 항상 부딪히는 문제가 있다.프로젝트에 맞게 스타일을 바꾸려고 하면 생각보다 손이 많이 간다는 것이다ㅠㅠ그런데 최근에 Headless UI를 알게 됐는데, 꽤 괜찮아서 공부해본것들을 정리해보려고 한다.https://headlessui.com/ Headless UICompletely unstyled, fully accessible UI components, designed to integrate beautifully with Tailwind CSS.headlessui.com우선 Headless UI 공식 홈페이지를 가면 아래와 같이 설명하고 있다."Completely unstyl..

사이드 프로젝트를 시작할 때마다 늘 똑같았다."일단 만들면서 생각하자"로 시작해서, 중간에 뭔가 꼬이고, 결국 처음부터 다시 짜는 패턴이었는데,이번엔 다르게 해보고 싶었다. 이미 기존에 유저 인증 관련 기능들은 개발을 해서 게시글 CRUD 기능을 개발 하기 전에 제대로 설계하고 시작하면 어떨까 싶어서 개발 명세서를 먼저 써봤다. 우선 프로젝트 개요, 기술 스택, 기능 요구사항 이렇게 크게 세 파트로 나눠서 작성했다.프로젝트 개요는 간단하게 프로젝트명이랑 버전, 설명 정도만 정리했고,기술 스택은 프론트엔드, 백엔드, 인증, 클라우드까지 어떤 기술을 왜 선택했는지 작성했다.기능 요구사항은 게시글 작성, 목록 조회, 상세 조회, 수정, 삭제 각각에 대해 상세 요구사항, 예외 케이스, 테스트 시나리오를 정리했다..

예전에 같이 개발을 공부하던 팀원들과 프로젝트를 만들때 속도감 있게 개발하자! 가 중요한 우선순위여서 나는 전통적으로 CSS 파일을 관리하기 보다 Tailwind CSS를 선택해서 프론트 개발을 했었다.그때의 나는 단지 Tailwind 가 쉽게 UI 개발을 도와주는 프레임워크라고 생각해 선택해서 사용했던 것 같다.그런데 프로젝트의 규모가 커지면서 기능들이 많아지고 구현해야할 UI 가 늘어나면서 점점 클래스가 길어지기 시작했다..결국 단순한 UI 하나를 수정하려면 긴~ 클래스 하나하나 살펴보면서 수정해야했다. 그러면서 Tailwind에 대한 나의 결론은 " 온보딩 하기에는 쉬우나 규모가 큰 프로젝트에는 못쓰겠구만! " 이였다.그런데 이번에 개인적으로 사이드 프로젝트를 개발하면서 역시나 같은 마인드로 .. ..