Tech 이모저모

오늘 기술면접 진행중에 면접관님께서 JSON에 관하여 물어보셨다. 그 중에서도 JSON.stringfy에 관하여 여러가지 물어보셨다.JSON.stringfy를 이용하여 객체를 비교하였는데 객체가 아닌 다른 값들을 대입하면 결과값이 무엇인지에 대한 질문이었다.사실 평소에

현재 회사는 기존 서비스를 Saas 형태로 전환하려 한다. 기존에는 기술 인력이 고객사에 방문하여 서비스를 직접 설치해 주는 방식이었다고 한다. 하지만 Saas를 통해 고객들이 사이트에서 설치를 직접하는 방식으로 사업모델을 변경하려 한다. 그래서 리액트 기반의 서비스

나는 Saas 프로젝트의 시작이 다가올 때 사내 디자인 시스템을 배포해야겠다고 마음먹었다. 컴포넌트들이 완성은 되었지만 실제로 라이브러리를 통해 사용해 본적은 없었기 때문이다. Saas 프로젝트 시작 전에 배포를 마치지 못한다면, 여태 만들었던 컴포넌트들의 코드를 새로

지난번 포스트에서 사내 디자인 시스템 배포에 관해 다루었다. 배포를 설정하고 나서 어려운 점이 있었다. 그 이유는 로컬환경에서 npm에 배포해야했기 때문이다. 그리고 작성한 코드를 두가지 경로에서 다루다 보니 관리는 더 어려웠다. 컨플루언스에 사용법을 나름 자세히 기록

내가 처음 입사한지 3개월이 넘어갔다. 약 3개월 동안 새로운 Saas 서비스를 쉼없이 만들어 왔다. 현재는 버그들을 잡거나 디자인이나 기능 변경이 되면 그에 따라 수정하고 있다. 아직 결재 기능을 위한 심사가 진행되고 있어 따로 기능을 구현할 일이 없다. 잠시 쉬어가

회사 업무 중 새로운 배열을 리덕스에 저장해야하는 상황을 마주했다. 그래서 new Array()를 이용하여 리덕스에 저장하였다. 빈 배열을 저장는 것이라면 위 방법이 큰 문제는 없지만 초기값을 설정해 주는 것이 매우 귀찮았다.예를들면 \[1,2,3,4] 를 선언한다고

버전관리이전 자동화에서는 새로 배포시 무조건 patch 명령어를 사용했다. 당시 자동화 코드를 작성할 때 patch가 정확히 무엇인지 모르고 사용했다. 버전이 동일하면 npm publish 실행시 에러를 발생해서 자동으로 버전을 높여주는 코드를 찾아서 사용한 것이었다.

사내 Saas 프로젝트에서 MVP기능을 구현한지 얼마 안된 시점이었다. 새로운 팀장님께서 오신 후 가장 먼저 각 팀원들과 1대1 면담을 하며 현재 코드나 업무에서 개선이 필요한 사항을 파악해 나가셨다. 나는 평소에 말수가 많지 않지만 그날 만큼은 한풀이 하듯이 내가 생

이전 글에서 언급했듯이 기존 디렉토리 구조는 작은 프로젝트에 적합했다. 이전 프로젝트 디렉토리 구조는 아래와 같다.components외의 디렉토리들은 모든 페이지가 공유를 해도 양이 많지 않아서 크게 어려움이 없었다.(사실 어렵긴 했다.) components는 문제가

처음 프로젝트 시작 시 팀원들과 파일과 변수명에 대한 논의를 거치지 않은 채 작업을 시작하였다. 따라서 파일이나 변수명을 보아도 어떤 역할을 하는지 파악하기 힘들었다. 특히 api 파일과 함수명이 문제가 많았다. api 호출 함수이지만 어떤 api를 호출하는지 파악하는

무엇이 문제인가 서비스에서 사용자는 많은 정보들을 입력해야한다. 아이디, 비밀번호, 이메일 기타등등.. 그리고 각 입력값들은 제한조건들이 존재한다. 예를 들면 이메일 양식은 영어와 @의 조합으로 구성되어야 한다던가 비밀번호에 특수문자가 포함되어 있을 수 있다. 제한조건

리팩토링 이전에는 컴포넌트 안에서 api 호출, redux dispatch, 에러 처리등을 모두 수행하였다. 컴포넌트의 기능이 점점 복잡해짐에 따라 api 호출 뒤 동작이 매우 복잡해졌다. 또한 하나의 api로 해결이 되지 않고 여러 api를 통해 원하는 동작을 구현하

처음 사내 프로젝트를 시작할때 redux를 사용했었다. 비동기 처리는 따로 하지 않아서 api의 결과물을 redux에 저장하고 필요한 컴포넌트에서 꺼내 사용했다. 그야말로 저장소에 가까웠다. 하지만 제품이 커지고 컴포넌트의 구성이 복잡해지면서 이런 방식은 불편한점이 많

프론트엔드에서 가장 흔하게 사용하는 라이브러리 중 하나는 axios일 것이다. 나의 팀도 axios를 당연하게 사용하였다. 하지만 사용하다보니 중복되는 코드가 많았고 과연 axios를 유용하게 사용하고 있는것이 맞는지 의문이었다.기존에는 api한개당 한개의 api 파일

처음 react 프로젝트를 진행할 때 typescript의 존재를 몰랐다. 당시 프로젝트를 도와주시던 멘토님이 "typescript 쓰면 좋은데.." 라고 탄식하셨다. 그때는 다른 언어를 배울 여유가 없어서 그냥 흘려들었다. 당시 작업하던 과정을 생각해보면, 머리속으로

디자인 시스템을 만들고 배포 자동화까지 많은 노력을 기울였다. 그리고 이렇게 만들어진 디자인 시스템은 팀원들과 디자인 팀의 업무에 많은 도움이 될거라 생각했다. 하지만 세상은 그렇게 호락호락 하지 않았다. 디자인 시스템은 어떻게 보면 규칙을 만들고 새로운 것을 규칙에

TDD를 배우고 싶던 프론트엔드 개발자의 교육 여정기

친구와 간단한 스터디로 리팩터링 2판을 읽고 매주 수요일 점심시간에 간단한 의견을 나누었다. 나는 평소에 강의나 직접 만들어보며 공부하는 것을 선호하기 때문에 이런 이론 서적을 끝까지 읽어 본 것은 처음이었다. 평소 실무에 사용하지 않아 생소한 내용들도 많았지만 나에게

쏙쏙 들어오는 함수형 코딩을 읽으며 함수형 프로그램은 왜 사용되는지 고민해 보았습니다.

실무를 진행하다보면 자연스럽게 API에 관한 이야기를 많이 하게 됩니다. 'PUT이 아니라 DELETE를 사용해야 할 것 같은데..', '이 경로가 맞나..?' 등 무언가 어색한 지점이 있기 마련입니다. 이런 표현은 대부분 RESTful 하지 않다로 함축할 수 있는 경

시작하며 F-lab 멘토링을 하다보면 다양한 주제가 나온다. 하지만 아는 내용이 많지가 않다. 그래서 이번에는 클린 아키텍처에 대해 알아보기로 하였다. 멘토님께서 번역글을 소개해 주셨고 프론트엔드에서 적용할 수 있는 클린 아키텍처에 대해 고민해보고 비슷한 예시로 코드를