프론트엔드 엔지니어로써 퍼블리에 합류하여 맡은 첫 프로젝트
PD와 논의를 통해 기존 협업 방식을 변경하였음.
기존 방식
디자인(PD) - 퍼블리싱(PD) - 엔지니어링(SE)
PD가 디자인한 후, 퍼블리싱 작업이 완료된 후 SE가 코드를 이어받아 작업 기존 방식은 불필요한 리소스가 많이 들어, 비효율적인 작업 방식이라고 생각하여 PD와 논의 후 작업 방식을 변경함
비효율적이라고 생각했던 부분
퍼블리싱 작업에 소요되는 시간 측면
Figma를 이해하고 퍼블리싱을 하는 SE & 프로젝트 코드를 이해하고 퍼블리싱을 하는 PD를 비교해서 생각을 해보았음. PD 업무를 하면서, Figma를 잘 다룰 수 있었기 때문에 스스로 Figma를 보고 퍼블리싱을 하는 것이 전체 리소스 측면에서 훨씬 줄어들 것이라고 생각하였고, 실제로도 그랬음.
기존에 가지고 있던 Figma에 대한 이해도를 차치하고서라도, 스프린트를 진행하면서 SE의 Figma에 대한 이해도는 계속 높아질 수 있지만, 수시로 변경되는 코드에 대한 이해도를 PD가 유지하는 것은 어려운 일이었음.
PD의 퍼블리싱 코드를 다시 작성하는 불필요한 작업
PD는 코드에 대한 이해도가 상대적으로 적기에, 컴포넌트 구조 등을 위해 코드를 새로 짜야했음. 퍼블리싱을 위해 작성한 코드에서 스타일링 부분만 남기고, 새로 코드를 작성하는 방식이 불필요한 작업.
스프린트 작업 시, SE가 참여하는 시점이 너무 늦어지는 문제
변경 후 협업 방식
디자인(PD) - 퍼블리싱 & 엔지니어링 (SE) - 디자인 리터치(PD)
변경 후 나아진 점
메이커 전체적으로 불필요한 리소스가 줄어들었음. PD는 퍼블리싱 리소스 대신 기획 단계에 참여를 더 할 수 있었음. SE는 Figma에 대한 이해도가 높아지고, 불필요한 코드 작업을 줄일 수 있었음.
서버 간 API 통신 시, 주고받는 데이터 구조로 인한 에러가 발생하는 것을 줄이고자 함.
기존에는 각 서버간에 주고받을 데이터 타입 정의를 통일하는 것으로 하였지만, 이는 코드 작업시에만 의미가 있고, 실제로 정의한 타입에 맞지 않는 경우에는 에러가 발생하더라도 막을 수 있는 방법이 없었음.
validation 라이브러리인 zod를 도입함으로써, 문제를 해결하고 안정성을 높일 수 있을 것이라고 생각하였음.
도입 전
zod 외 해당 문제를 해결하는 다른 방법 또는 라이브러리가 있는지 확인