728x90 반응형 lean/주간 회고71 23.12.11~23.12.17 업무 onboarding package 아키텍처 변경 문제점 지난주 금요일. PoC 대상 기업의 기획안을 전달받아 우리 서비스를 적용했다. 기존 생각했던 기능에서 크게 벗어나지는 않았지만, 실 production 환경에서 테스트를 해보니 이것저것 수정할 사항들이 발견되었다. 그런데 그 과정에서, 시스템 복잡도가 걷잡을 수 없이 커져버렸다는 생각이 들었다. 해당 패키지를 처음 개발했을 당시만 해도 명확한 기획안이나 요구사항이 존재하지 않았다. 따라서 구체적인 협업 방향이 나오기 전까지는 어떻게 되든 반드시 필요한 기능을 부분적으로 개발하고자 했고, '온보딩 요소들을 생성한다', '사용자 페이지에서 특정 요소를 찾는다' 등의 개별 기능들만 존재했었다. 점차 협업 기업이 늘어나며 요구 사항이 구체화되었는데 요.. 2023. 12. 17. 23.12.03~23.12.10 업무 ActionType 관련 변경사항 반영 기존 DB 및 비즈니스 로직이 요구사항을 정확히 구현하지 못하는 이슈가 있었다. DB 설계 당시에는 '최대한 확장성이 좋게 설계해 보자!'라는 취지였는데... 막상 실제 유저들의 요구사항이 구체화되고, 사용 습관을 살펴보니, 해당 로직으로는 오히려 이를 정확하게 구현할 수가 없었다! 이미 작업된 사항들도 제법 많았고, 관련 부분이 이미 한 번 변경된 적이 있었던 터라 해당 변경 사항에 반대하는 팀원도 존재했다. 1) 요구사항 구현이 불가능한 현재 상황 진단 2) 가능 해결책 나열 3) 각 해결책 별 장단점 비교 4) 일정 + 추후 안정성 및 유지보수 용이성 + 현제 수정 작업량 고려 등의 단계를 내부적으로 거쳤고... 내가 제시했던 방향으로 합의가 이뤄져, 이.. 2023. 12. 11. 23.11.26~23.12.03 업무 가이드 빌더 패키지 개발 기존 모달 형태의 가이드 빌더에서, 툴팁 템플릿이 추가되어 이를 개발했다. 대상 조회 및 툴팁 생성 extension에서 사용자가 선택한 요소의 xPath를 생성해 저장하면 script에서 xPath에 해당하는 요소를 찾아, UI에 맞는 툴팁을 띄워주는 형태로 구현했다. 요소를 찾는 것 자체는 간단했지만 사용자가 선택한 방향에 따라 말풍선의 위치를 변경하고, 해당 요소를 클릭하면 다음 툴팁이 뜨면서 동시에 배경이 깔려야 하는데... 아래 작성한 반응형 대응과 합쳐지면서, 생각보다는 애를 먹었던 작업! 반응형 대응 xPath로 요소를 조회하는데... 여기에는 치명적인 문제점이 있다. → DOM 변경 및 화면 resize시 반응형에 대응해야 한다는 것! xPath요소가 존재하지.. 2023. 12. 3. 23.11.19~23.11.26 업무 1. component update module 개발 extension에서 생성된 template의 component들을 수정할 수 있는 모듈을 작성했다. component 속성 중 content, image, url, action에 대한 수정 액션을 제공해, 사용처에서 해당 값들을 입력받아 업데이트가 이뤄질 수 있도록 했다. 2. UI styling 각 template sub category마다, 해당 UI별 고유한 frame이 존재한다. 현재 협업 중인 회사의 frame 2개가 존재하는데, 이에 대한 UI 작업을 마무리했다. 추가적으로 좌우측 패널이 사용자 액션에 따라 위치가 변경되기도, 사라지기도 하는데 이를 context로 분리해 panel의 style값의 변경사항을 하위 컴포넌트에 전파해 .. 2023. 11. 26. 23.11.12~23.11.19 업무 공유 1. Step 제어 모듈 작성 현재 온보딩 빌더는 tree 구조 형태로, 각 node가 자신의 다음 node에 대한 정보를 알고 있다. 이때 각 간선을 action이라는 속성으로 저장하는데, 해당 데이터를 어떻게 바라볼 것인가! 의 정의가 변경되어, 이를 반영했다. 처음에는 UI 로직을 따라 각 action이 '다음', '이전', '특정 node로 이동', 'url이동' 등으로 구성되어 있게 설계했는데, 의미를 따지고 보니 '다음'과 '이전'이 결국 '특정 node로 이동'함과 동일하다고 판단되었다. 물론 이 경우... 각 node들의 순서가 변경될 때 action 역시 변경해야 한다는 불편함이 있었지만, 이렇게 하지 않을 경우 각 node들이 자신의 순서(order개념)를 갖고 있어야 하고 .. 2023. 11. 19. 23.11.05~23.11.12 업무 1. 변경된 DB 구조 반영 지난주. 다른 기업과 협업을 진행하면서, 기존의 DB 구조로는 앞으로의 요구 사항을 반영하지 못하겠다는 판단을 내렸다. 이로 인해 협업 이전 진행하던 개발 사항들을 모조리 수정해야 했는데... 해당 작업에 4일 정도를 투자했다. 물론 단순히 DB 측 interface만 변경하는 것이라면 (이것보다는) 간단했을 테다. 하지만 협업을 진행하며 package 쪽 아키텍처도 개선이 가능하겠다는 생각이 들었어서, 이를 반영해 새로운 모듈들을 추가적으로 작성했다. 그 과정에서 특히 FE 개발에서는 1) 무엇을 추상화할 것인가 와 2) 관심사를 어떻게 분리할 것인가 를 계속해서 고민해야 함을 느꼈다. 물론 소프트웨어 개발에서 적절한 추상화와 관심사 분리의 중요성은 말해 입 아프겠지만.. 2023. 11. 12. 23.10.22~23.11.05 업무 1. first customer용 프로덕트 개발 0번째 고객을 모으는 건 언제나 어렵다. 하지만 반대로 말하자면, 모든 프로덕트는 0번째 고객부터 시작한다. no-code onboarding builder라는 콘셉트만 존재하는 현 상황에서 정말 감사하게도, 한 스타트업과 협업을 진행하게 되었다. 월요일에 최종 디자인을 전달받았고... 무엇보다 속도가 중요하다는 판단이 들어, 단 삼일 만에 모든 개발을 완료했다! (정말 홀린 듯 일했다...) 2. DB 구조 전체 변경 협업이 진행되기 약 한 달 여 전부터, 전체적인 설계 및 api 개발, 패키지와 extension 개발이 진행되고 있었다. 하지만 협업을 진행하는 삼 일 간... 해당 기업의 요구 사항을 현재 DB 구조로는 구현하기 힘들겠단 생각이 들.. 2023. 11. 5. 23.10.22~23.10.29 업무 1. 신규 서비스 기능 개발 폭풍 같이 몰두한 한 주... a. 전체 아키텍처 구성 기본적인 애플리케이션 구조를 설계했다. 가장 신경 쓴 부분은 → 각 컴포넌트들 간의 관심사 분리. 지금껏 운영해 온 여러 서비스들을 생각해 보면 유지보수와 확장이 용이한 프로젝트도, 그렇지 않은 것도 있었다. 그 차이를 곰곰이 생각해 보면... 물론 여러 이유가 있겠지만, 애플리케이션의 최초 설계 역시 제법 큰 부분을 차지함을 느꼈다. 최초 설계 시 명확하지 않은 개념(올바르게 분리되지 않은 관심사)들은 필연적으로 개발자 각각의 정의로 이어졌고, 이로 인해 각 컴포넌트나 함수의 관심사가 모호해지는 경우가 허다했다. 따라서 지금까지 나온 요구사항에 기반해 핵심 상태 및 제어 로직과 전체 컴포넌트 구조를 정의하는데 노력.. 2023. 10. 29. 23.10.15~23.10.22 업무 1. 온보딩 요소 생성 관련 추가 개발 Builder class들을 통해 온보딩 시 띄워줄 HTMLElement들을 생성하고 있는데, 이 부분의 추가 개발을 진행했다. (배경, action 제어 등) 2. 공통 모듈 패키지 제공 메인으로 진행했던 업무! 사용자가 온보딩을 등록한 후, 해당 데이터를 배포하면 서버 측에서 해당 온보딩을 보여줄 수 있는 script 파일을 번들링 하고 있다. → 온보딩을 화면에 띄우는 데 필요한 로직은 모두 server에 작성되어 있었다. 그런데 client 측에서도 등록 중인 온보딩을 미리 봐야 하는 요구 사항이 있었고... 해당 기능을 구현하는데 필요한 로직의 90% 정도가, 이미 서버에 작성된 내용과 동일했다! 모든 파일을 복사 붙여 넣기 하기엔 유지보수 리소스가 .. 2023. 10. 22. 이전 1 ··· 3 4 5 6 7 8 다음 728x90 반응형
