16주차 개발일지

나만의 무기 2주차

Second

첫 발표 이후

첫 발표 이후 주제에 관하여 고민하던 도중 쇼핑몰을 운영했던 시절 생각해왔던 통합 장바구니 아이디어를 팀원들에게 공유했다.

우리팀은 우리가 실제로 사용하고 싶은 지와 기술적 챌린지 및 확장성에 대해 중점을 두고 고민을 하고있었고,

내가 제안한 주제에 대해서 실제로 사용하고 싶은 어플리케이션은 맞지만, 기술적 챌린지에 대해서 걱정이 많았다.

검색을 해보니 시중에 이미 주제와 관련된 어플리케이션이 있었고, 그에 반해 차이점과 기술적 챌린지에 대한 고민을 많이 해보았다.

이에 대한 우리의 결론은 다음과 같다.

1. 방향성

• 개인적 장바구니에 그치지 않고 함께 공유하며, 의사결정까지 도와주는 어플리케이션을 만들어 보기로 결정했다.

1. 기술적 챌린지

• 얼마나 효율적으로 많은 쇼핑몰들로부터 스크래핑을 할 것인가
• 실시간 가격변동, 재입고를 어떻게 사용자에게 알림을 해줄 것인가

1. 확장성

• 실시간 채팅, 화면 공유, 동시성

기술 스택 선정

React-Native 선정 배경

1. 우리는 실제로 사용하고 싶은 어플리케이션을 만들자라는 것이 목표였던 만큼 많은 사용자들이 이용할 수 있도록 IOS / Android 모두 배포하는 것이 목적이였다.

• 하나의 프로그래밍 언어로 IOS와 안드로이드 모바일 앱을 동시에 개발할 수 있다는 장점(코틀린, swift를 선택하지 않은 이유)

1. React (pwa) 를 선택하지 않은 이유 ?

• 프로젝트 핵심 기능을 구현하기 위해선 네이티브 브릿지를 통한 네이티브 언어와 통신 해야 했다.

1. Flutter 를 선택하지 않은 이유 ?

• Flutter에 비해 React-native가 생태계 조성이 잘 되어있어 라이브러리 활용이 용이하다.

Share-Extension

우리 프로젝트의 핵심기능인 앱 밖에서 앱안으로 아이템을 추가하는 공유기능을 하려면 IOS 기반으로 이루어진 share-extension을 사용해야 했고, Android도 마찬가지 kotlin기반 extension을 사용해야 했다.

하나의 언어로 두 네이티브를 연결할 수 있다는 장점이 있지만, 네이티브 기능을 연결하는 것이 정말 어렵다는 문제를 마주했다.

주제 선정 이후 3일 밤새 이 핵심기능 하나를 위해 매달렸지만, 결국 구현하지 못했다.

발표 이후 결국 구현을 했는데 이유는 다음과 같았다.

1. 의존성

• 오픈 소스이기 때문에 업데이트가 자주 발생하고, 업데이트 시 수정된 기능들 때문에 버그가 발생할 수 있다는 것
• ruby 언어로 이루어진 podfile의 오타 (띄어쓰기)
• xcode ↔ vscode 비동기화

1. 느낀 점 & 배운 점

• 프론트의 기술은 정말 빠르게 변화한다고 하는데 처음으로 피부에 와닿았다.
• 각각의 프로그램은 하나로 이루어진 것이 아닌 여러 프로그램이 서로 의존성관계를 유지하고 있기 때문에 상호 의존성을 잘 맞추어 주어야 한다.
• 의외로 React-Native 참조글이 굉장히 부족해 공식문서를 최대한 파고들었는데 수많은 구글링을 통해 얻은 답은 공식문서가 제일 빠르고 정확하다.

중간 발표 (01/05)

또 한번의 패배를 맛보았다..

다른 팀들은 기본 핵심기능을 거의 다 구현한 반면 우리는 핵심기능 하나 조차도 제대로 완성하지 못했다.

돌아온 피드백은 도대체 뭘 보여주고싶은 것인가였다. 구현된 것이 없으니 당연히 이해도 되지 않을 수밖에

우리팀은 다시 한번 이를 악물고 처음부터 시작하는 마음으로 핵심기능을 구현하고 엉망진창으로 얽혀있는

UI 부터 새롭게 다시 짜고 시작했다.

Fetch vs Axios

기본적인 CRUD 기능을 구현하기 위해 Fetch / Axios 중 어떤 함수를 사용할지 고민이 되었다.

Axios가 JSON 데이터를 자동으로 변환해주기 때문에 편안하게 사용할 수 있고 세부적 기능이 더 많은 장점이 있는 반면, 자바스크립트의 내장 라이브러리는 아니기 때문에 업데이트 의존성 문제가 빈번히 발생해, 안정성을 위해 Fetch를 선택했다.