🕒기간: 21.4.19 ~ 21.4.30(2주)
😀인원: 4명
- front: 이종호, 이재영
- back: 이서준, 이서진
💡느낀 점(1차에 비해)
1차 때 이런 저런 개선안을 생각하고 들어갔지만,
여러가지 이유에 의해 잘 개선되지 못했다.
1. 고단한 일정..📉
세상에 안 힘든 사람이 어디있고, 고작 몇 주 한거 가지고 벌써 지치냐 할 수 있지만,
생각보다 정신이 많이 지쳐있었던 것 같다.
1차 때의 경험을 미처 다 소화하기도 전에 2차를 시작해야 했고,
어렴풋이 이래야 할 것 같은데 같은 직감에 의존한채 프로젝트를 진행하게 되었다.
2. 인원이 4명(초큼 적은 듯..)
분명 인원이 많고 적음에 따라 장 단점이 있겠지만,
제일 아쉬운점은 여러 사람의 의견을 들어보지 못한다는 것이었다.
여러 사람의 의견을 나눠보면서 진행했다면 일정조율이나 의견제시 측면에서 더 좋았을 것이라 생각이들었다.
3. 새로운 기술 스택(Hook, styled-components)
나는 이전에 react로 잠시나마 프로젝트를 진행해봤고,
그래서 1차에서는 기술적으로는 크게 어렵지 않았다.
하지만 2차에서는 위코드 답게 새로운 기술스택을 권장했고,
react-hook, styled-components를 사용하게 되었다.
물론 실제 써보니 그렇게 어렵진 않았다.
하지만 이게 나중에 어떤 문제를 만나면서 복잡도가 많이 늘어났는데, 후에 그 것을 다루겠다.
하지만 어렵지 않다는 것은 좀 써보고 난 후의 느낌이고,
1~2일에는 새 기술을 어디까지 공부해야 하나, 내가 모르는 것이 뭐가 있나,
이런저런 부담감이 팀원과의 소통에서 움추려 있던 원인 중 하나였다.
Naver Map API
우리의 클론 프로젝트는 다방이었고,
당연히 맵을 쓰는 것이 주요 과제였다.
(왜 네이버 맵을 썻냐고 물으신다면, 그냥 다방이 네이버 맵을 썻기에 따라 썼습니다.)
솔직히 맵을 구현하는 것 자체는 쉬웠다.
예제들도 잘 나와있었고, 적당히 따라하니 예제들을 리액트에 뿌려주기까지는 쉬웠다.
문제는 커스텀 오버레이를 사용하면서 터졌는데,
커스텀 오버레이란 개발자가 원하는 형태의 무언가(이미지든 글이든 원하는거 다!)를 맵에 띄우는 걸 의미합니다.
https://navermaps.github.io/maps.js.ncp/docs/tutorial-custom-overlay.example.html
var CustomOverlay = function(options) {
this._element = $('<div style="position:absolute;left:0;top:0;width:124px;background-color:#F2F0EA;text-align:center;border:2px solid #6C483B;">' +
'<img src="./img/example/brown.png" style="width: 120px; height:130px">' +
'<span style="font-weight: bold;"> Brown </span>' +
'</div>')
this.setPosition(options.position);
this.setMap(options.map || null);
};이 코드는 실제 예제에서 저 곰 사진(이름이 있었던 것 같은데..) 을 만들 때 사용한 코드로
JQuery로 되어 있었다.
당연 나는 "으례 React개발자라면! 컴포넌트로 구현 해야지! 암!"
이런 생각을 가지고 있었고, 어찌저찌 구현을 하긴 했다.
거기까지 가는데 총 일주일이 걸렸다.
(
어디어디 페이지 할건지 정하고~
초기설정 하고~
로그인, 회원가입 하고~
페이지 레이아웃 잡고~
예제 구현해보고~
제이쿼리를 순수 JS로 해보고~
순수 JS를 JSX로 해보고~
실제 리액트 실행해서 원하는대로 뿌려지는지 확인하고~
)
증거 사진을 좀 찍어둘걸 그랬다.
못 믿으실 수 있지만 나름 진짜 컴포넌트로 잘 구현했다.😢
문제는 다시 불러올 때,😂
다방의 맵은 조건이 달라질 때 마다 거기에 해당하는 것들이 맵에 다시 그려졌다.
하지만 나는 다시 그릴 때 알 수 없는 에러가 뜬다는 것을 늦게 알아 챘다.
원인을 고민해 봤을 때, 다른 스테이트를 수정하면서 재 렌더링이 되는데,
그게 커스텀 컴포넌트가 없는데 그리려하는? 그런 시도를 해서?
아무튼 설명하긴 어렵지만, 맵을 그리는 동작과, 조건 state(ex. 관리비)에 의한 렌더링 중에서 선 후 관계에 의해 없는 값을 참조하게 되어 발생되는 에러였던 것 같다.
(그걸 if문으로 처리해도 뭔가 그냥 안됐다. 기억이 안난다..)
그래서 계속 어떻게 하면 될 까 코드를 고치고 했지만,
워낙 급하게 하기도 했고, 솔직히 원인이 정말 저거인지, 페이지 렌더링 될 때 다른 무언가의 개입이 있는건 아닌지 정말 모르겠더라.
(아직도 잘 모르겠다 부끄럽다.. 빨리 알아봐야겠다. 하지만 지금 당장은 어려울 것 같다. 급하지 않고 천천히 눈앞의 문제부터 해결해보자.)
그러면서 하루하루 시간은 지나갔고, 머릿속엔 부정적인 생각만 가득찼다.
그렇게 발표 하루 전날 지푸라기를 잡는 심정으로 종택 멘토님에게 도와주실 수 있냐고 간청을 했고, 멘토님도 2시간 가까이 끙끙 앓다가 10시 가까이 되자(이때 위코드는 10시가 되면 나가야 했다.) 내일까지 작동되는 코드를 가져오겠다 하고, 내일보자 하셨다.
그리고 새벽 3시 까지(백엔드와 같이 작업했기 때문에 그분에게 시간을 들었다.)작업을 하시고
아침에 코드를 보내주셨다.
솔직히 그 때, 좀 인간적으로 많이 고마웠다.
당시 위코드에선 멘토님들이 늘 한정적인 자원(?)이었다.
코드 리뷰하랴, 수업 준비하랴, 질문 받아주랴..
진짜 그분도 정신적으로 힘들다는 사실을 같이 지내며 알고 있었다.
그러면서 나 하나(40명이 넘는 인원 중) 때문에 2~3시간 가까이 내 코드를 지켜주려고 하면서, 어떻게든 되게 하려고, 시도해주시고, 그러는 와중에도
"할 수 있어요, 할 수 있습니다." 라며 긍정적으로 힘내주시는 모습에
정말 여기서 같이 일하고 싶은 개발자란 무엇인지 느꼇다
실력도 실력이지만,
힘들어도 그렇게 부정적이게 되지 않기,
끝까기 힘내기, (웃으면서)
최선을 다하기 등이 느껴졌다.
써보고 보니 당연해 보이지만, 절대 쉽지 않은 일이라 생각한다.
결국, 발표날 아침, 종택님의 코드를 받았고,
받은 직후 필요한 기능들을 급하게 가져다 붙이고 부족하지만, 어느정도 완성된 모습으로 발표를 마칠 수 있었다.
발표 직전까지 코드에 이런저런 기능 넣어야 했기에 고맙다는 인사도 까먹고 못드렸는데,
그 일로 종택님은 나만보면 뭐라 하셨다.죄송합니다.
죄송합니다.. 정말루...
정말 말로 표현하지 못할정도로 고마워서 말을 못하고, 미루다 까먹었습니다..ㅠㅠ
종택님에게 감사하다.
단지 코드를 고쳐줘서가 아니라
팀에서 좋은 개발자란 어떤 모습인지 옆에서 경험할 수 있게 해줘서 그렇다.
실력도 실력이지만,
그 분이 나에게 보여주었던 행동들은
앞으로의 내가 개발자를 하든 다른 직업을 하든, 하나의 이정표가 되게 할 것이다.
