-
Notifications
You must be signed in to change notification settings - Fork 2
📝 아이디어 회의 (작성일 : 2024 10 29)
- 분류: 정규 회의
- 생성 일시: 2024년 10월 29일 오전 10:00
- 선택: 회의록
@Zen :: 기존에 이야기를 한 것은 디자인적인 측면이 강한 것 같았다.
@혜인 정 :: A11y에 대한 아예 접근성을 고려하는게 좋을 것 같다. 접근성자체를 기술적으로 가져가봐도 좋을 것 같다.
@혜인 정 :: 지도에 대한 상태관리를 해봐도 좋을 것 같다. 치킨집마다 다른 뿌링클 맛을 평가하는 웹사이트가 있었으면 좋겠다 해서 전국 뿌링클 맛집 지도를 만든적이 있는데, 전국 맛집에 대한 마킹을 해두고 마킹 별로, 리뷰를 넣을 수 있는 그런 식으로 사용을 했다. 네이버 지도 API나 카카오 지도 API를 사용하면 그건 진짜 간단하다. 기술적인 도전으로 가져가기에는 아쉬움이 있을 것 같다. 상태관리에 대한 기술적 도전보다는 API적용에 대한 기술적 도전이 될 것 같다. 포트폴리오적으로 맞지 않을 것 같다.
@Zen :: 위치 정확도를 올리고 싶으면 알고리즘을 건드려야 한다.
@Zen :: 기술적인 도전을 할 거면 2개를 생각해볼 수 있을 것 같다. 1. 지도 만들기. 2. 실내에서 위치 안내해주기. 다만, 이 경우는 FE프로젝트라기 보다는 임베디드, CS 프로젝트가 될 가능성이 있다.
@혜인 정 :: 위치에 대한 것에 집중하면 threejs라는 기술 자체에 도전하는 것과 다를게 없을 것 같다. 기술적인 도전을 했으면 좋겠다.
@혜인 정 :: 그냥 멘토님께서 말씀하신 스토리북을 도입해서 프론트엔드 개발적인 도전을 해보자. 주제는 어제 정한 걸로 동일하게 하고,
@Zen :: A11y로 할 것이라면 TDD로 하자. 그냥 TDD를 넘어서 모든 과정을 테스트하고, 이를 기술적인 도전으로 삼자.
@동율 이 :: 뭐든 “왜?” 라는 질문에 대답을 확실히 할 수 만 있으면 상관이 없을 것 같다.
@주원 김 :: 6주동안 TDD하는게 잘 없을 것 같아서, 면접때 주제를 모을 수 있고.. 장점이 많을 것 같다. 딥다이브한 범위 내에서 주제를 가져갈 수 있을 것 같다. 부정적이면 부정적인 이유를 나열할 수 있고, 등등.. 다만 확장성에 대한 부분
@동율 이 :: 실시간 위치나, 접근성이나 UX도 디자인적인게 강하다. 이에 대해서 기술적 도전을 할게 아니라면 TDD등 평소에 해보기 어려운 확실한 주제를 잡아서 가는 게 좋을 것 같다.
@혜인 정 :: 우리가 할 수 있는 제일 큰 기술적인 도전인 것 같다. 구현하는 데 신경을 많이쓰면 TDD를 도입하기 어려울 것 같다. 우리가 구현할 수 있는게 적어야 할 것 같다. 간단한 프로젝트 처럼.
@혜인 정 :: 문서화를 도전으로 해봐도 좋을것 같다.
@동율 이 :: 문서화는 기술적 도전이 아닌 것 같다. 굳이 TDD가 아니더라도, 다른 방법으로 고민해봐도 좋을 것 같다.
@주원 김 :: 여행계획 TodoList로 가더라도, 주제는 좀 짜쳐도 상태관리 TodoList로 넣어도 괜찮지 않을까? 계획 세우기를 J식으로 해서 상태관리를 해봐도 좋을 것 같다.
@Zen :: 시간이 부족할 것이라는 생각이 든다면, 코어타임 규칙을 깨자. 코어타임까지만 개발을 하더라도 문서화, 공부는 그 외시간에 하는 게 맞다고 생각한다. 내가 생각하는 일정 산출에는 학습 시간 및 문서화 시간은 포함되어 있지 않다.
@혜인 정 :: 주제만 작게 잡으면 시간적인 측면에서는 상관 없을 것 같다.
@Zen :: 문서화나, 학습은 코어시간 이후에 진행하자. 대신 학습을 하면 동기화는 빠르게 하자.
@혜인 정 :: 프로젝트가 작으면 테스트를 할 게 그만큼 적어진다.
@Zen :: 그럼 아예 클론 코딩을 해버리는 건?
- 어떤 주제를 하든 상관없으나,
TDD등 모든 과정에 대한 테스트 주도 개발을 기술적 도전으로 함. - 주제는 위치관련된 것이면 된다. ↔ 자유롭게 해보고 최대한 고려 (포폴적으로 확실하게…)
- 코어타임시간에는 온전히 개발만. 일정 산출도 개발진도에 대한 부분만. (늘어짐 방지) - 회의시간은 포함 → 테스트코드 작성
- 문서화 및 학습은 코어타임 이후에 자유롭게. 적게하든 많이하든 무조건 코어타임 이후. (개발하면서는 최소한의 것만 보기.)
-
문서정리 → 아카이빙해서 가져가면 좋을 것 같다는 생각… 나중에 회으ㅜ
-
이후 쉬고와서 :: 주제선정
최대한 노션 페이지는 안만들고 여기에 적을게요. GPT가 잘 인식을 못하네여 ㅠㅠ..
나중에 따로 아카이빙 하겠습니다.
테스트 with Jest: 제로초에게 제대로 배우기 강의 | 제로초(조현영) - 인프런
2시간으로 끝내는 프론트엔드 테스트 기본기 강의 | 강병진 - 인프런
- 생각해보니 Cypress도 있었네요. 당근은 이거쓴다던데
실무에 바로 적용하는 프런트엔드 테스트 - 1부. 테스트 기초: 단위・통합 테스트 강의 | 코드 조커, 오프 - 인프런
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트 강의 | 코드 조커, 오프 - 인프런
근본있는 프론트엔드 유닛테스트 강의 | 어쩔코딩 - 인프런
- 개인적으로 만약 TDD 프로젝트로 가면 이 바이블 책 정도는 읽어봐야 할 것 같아서, 이걸로 그룹프로젝트 내부 스터디해도 재밌을 것 같습니다.
코드와 함께 살펴보는 프론트엔드 단위 테스트 – Part 1. 이론 편 | 우아한형제들 기술블로그
코드와 함께 살펴보는 프론트엔드 단위 테스트 – Part 2. 실전 편 | 우아한형제들 기술블로그
프론트엔드 개발자가 알아야 할 ‘유닛 테스트’ 작성법 | 요즘IT
실용적인 프론트엔드 테스트 전략 (1) : NHN Cloud Meetup
[A5] 프론트엔드에서 TDD가 가능하다는 것을 보여드립니다.
@혜인 정 :: 걸리는게 뭐냐면, TDD가 현업에서 부정적인 이미지가 많은데.. 이걸 써야하는 게 후킹하지 않다고 생각한다. 예시를 들면 멘토님이 써야하는 프로젝트가 전역 상태 라이브러리를 써야한다는 방향으로 나아갔다. 거기에서 Context를 써보고, 안좋은 것이 있다는 것을 발견했고, 그래서 왜 안좋은지 알 수 있었다가 흐름이 되는건데… 우리로 따지면 전역상태관리를 쓰지 않고 그냥 useContext가 됐다. 라고 생각한다. 우리로 치면 useContext가 TDD라고 생각한다. Storybook이 Redux가 아닌가 싶다. 많이 바뀌고, 테스트코드가 바뀌기 때문에 비효율적인것 같다가 대다수고… 간단한 스토리북을 사용하는 경우가 훨씬 많고. 제가 생각했을 때는 멘토님이 useContext를 썼을 떄 그정도로 후킹했을까 싶다.
@주원 김 :: 썻을떄 비용은 많이 들었지만, 코드가 어떻게 변했다. 이게 포커싱이 될 것 같다. TDD를 썼을때의 효과는 이거이거했으니까 좋고, 전 프로젝트는 어떤 관점이 부족하고… 사이드이펙트가 생길지 몰랐는데.. 다음 프로젝트는 이거이거… 그렇게까지 하는게 되는게 아닐까 생각하고있다.
@혜인 정 :: 결론이 부족한게 너무 걸린다…
@혜인 정 :: 테스트와 빡센 문서화면 프로젝트로도 가치가 있을 것 같다.
@Zen :: 테스트를 제대로 할 수 있으면 좋을 것 같다. (팀 전체가 동의한다면)
@주원 김 :: 일단 써보자가 의의인 것 같다. 일단 그래도 쓰자 라는 주의이다.
@동율 이 :: 테스트를 하고 싶어 하는 것 같다. 테스트가 주가 되기 보다는 어디서든 쓸 수 있다. 굳이 좋은 주제가 있는 게 아니면 그대로 써보자.
@혜인 정 :: 일단 어제 정했던 주제로 가서 TDD를 입히고, 거기서 해보는 걸로 가자.