Week 4
Day 1
- 마이페이지 레이아웃 구현 완료 (미디어쿼리 일부 적용 완료)
- png 파일 svg 파일로 변경 완료
- 위클리 미팅 : 현황 보고 및 1월부터의 작업을 위한 가이드를 받음
- 본격 업무 들어가기 전 WBS 작성 준비
- 메인페이지 레이아웃 구현 시작
오늘 처음으로 png나 jpg가 아닌 svg파일을 삽입해보았다. svg 형식의 파일은 용량이 비교적 작으면서도 해상도가 깨지지 않고 깔끔하게 이미지가 삽입되는 장점을 가진다고 한다. 나는 기존 이미지 형식과 동일하게 소스만 교체하면 될 거라고 생각했는데, svg 파일 삽입 시 이미지 사이즈가 완전히 달라지는 문제가 발생했다. 추측하기로는 이미지 파일은 디자이너가 사이즈에 맞게 작업한 자료이고 svg 파일은 그렇지 않아서 인 듯 하다. 그래서 이미지가 들어가는 각 구간에 새롭게 이미지 사이즈를 지정해줌으로써 이전과 동일한 UI를 그릴 수 있었다.
그리고 오늘 위클리 미팅을 진행하며 새로운 개념 몇 가지를 듣게 되었다. 첫 번째는 WBS(Work Breakdown Structure). 내가 이해한 바에 따르면, WBS는 효율적인 프로젝트 진행을 위해 업무 일정을 계획하고 관리할 수 있는 기초 문서이다. 프로젝트 목표 달성을 위해 필요한 모든 업무를 계층화하여 작성함으로써 진척상황을 한 눈에 파악할 수 있고, 이를 통해 전체 프로젝트의 일정을 효율적으로 관리할 수 있도록 돕는다. WBS 샘플 자료를 봤는데 보자마자 기능 이해 완료! 예전 광고쟁이이던 시절 광고주에게 보고하기 위한 tracker와 비슷한 역할인 것 같다.
두 번째 개념은 OBT(Open Beta Test). 풀네임으로는 많이 들어봤는데 줄임말로 OBT라고 부르는지는 처음 알았다. 게임 업계에서 주로 들었던 그 의미 그대로, 불특정 다수를 대상으로 진행하는 외부 테스트를 말한다. 이 과정을 통해 본격 서비스 출시 전, 다수의 동시 이용자가 존재하는 상황에서의 안정성이나 내부테스트로 잡지 못하는 에러들을 발견하고 해결할 수 있다.
다음 달부터는 OBT 진행 전 내부테스트를 위한 준비를 하게 되는데, 매우매우매우 기대된다..!!!!
Blocker
redux의 벽을 꾸역꾸역 넘었더니, 이젠 새로운 문제 발생..! 페이지 내에서 사용자가 새로고침 버튼을 누르면 당연히state값은 (redux를 썼든 아니든) refresh되며 초기값으로 되돌아간다. 이 당연하고도 당연한 로직을 왜 인지하지 못했을까!! 너무 당연해서 습관처럼 지나갔던 것 같기도 하고..
state가 초기값으로 돌아가게 되면 로그인 상태라던가 기타 등등 유지되어야 하는 부분이 사라지게 되어 문제가 발생하게 된다. 검색해보니redux-persist로 해결할 수 있는 것 같아 추가적으로 반영 예정.
서비스를 개발할 때에는 사용자가 할 행동을 대략적으로 예측하고 그에 대한 상황을 대비해야 한다는 말을 들었다. 번거롭다는 생각이 들더라도 안정적인 서비스를 위해 하나하나 잘 대처해 나가보자!!
Day 2
- 메인페이지 레이아웃 및 미디어쿼리 구현 완료
- 페이지 네이밍 수정
- 재정거래봇(채굴) 페이지 레이아웃 및 미디어쿼리 구현 완료
- header 내 아비봇 로고 클릭 시
nav메뉴 비활성화 되도록 구현 - header 미디어쿼리 구현 중
아비봇 웹의 메인 페이지는 꽤나 다양한 정보를 보여주는데, 그 중 가장 핵심적이라고 볼 수 있는 부분이 실시간으로 업데이트되어야 하는 정보가 많이 분포해있다는 점이다. 아직 기능 구현 및 API 연동 전 이기는 하나, 이런 부분들을 생각하면서 레이아웃을 구현하다 문득 든 생각이 있었다.
"지금 내가 구현하고 있는 방향이 웹 페이지의 성능에 영향을 미치지는 않을까?"
React는 컴포넌트로 나누어 작업을 하지만 최종적으로는 단일 페이지로 동작하는 SPA이다. 각 페이지에서 작동하는 state값은 다른 페이지에 영향을 주지 않지만 (redux를 쓰면 전역으로 관리) setState가 일어날 때마다 페이지 전체가 랜더링 되는 것. 실시간으로 데이터를 받아오게 되면 그 때마다 state값은 변화할 것이고, 전체 페이지에서 재랜더링이 발생하게 된다. 과연 이게 올바른 걸까? 다른 방법은 없는걸까?
잠시 시간을 내어 검색해보니 function component에서는 useMemo라는 hook을 활용하면 조금 더 나은 성능의 웹을 개발할 수 있다고 한다. 더 깊게 공부를 해봐야겠지만 대략적으로 살펴본 바에 의하면, 이전의 값을 저장하여 state값에 변화가 일어나 재랜더링이 발생했을 때 새로 들어온 값과 이전의 값을 비교하며 값에 변동이 없다면 저장된 이전의 값을 참조하는 것이다.
어떠한 방식으로 작동이 되는지, 어떤 상황에 적용했을 때 가장 효율적인지 조금 더 공부해봐야겠다.
+) 오늘도 역시 컴포넌트화에 대한 고민은 끊이지 않음. 어디까지 분리해야하는가, 어떤게 더 유지보수가 수월하고 가독성이 높을까.
Day 3
- header & main 페이지 미디어쿼리 구현 완료
- 1월 중 진행될
내부테스트스케줄 회의 및 정리 - 업데이트 필요한 소소한 내용 반영
오늘의 메인 업무는 1월 10일부터 진행될 프로젝트 관련한 스케줄링이었다. 1월 말을 기점으로 내부테스트가 예정되어 있는데, 어느 부분까지 개발할지, 어떤 내용을 중점으로 생각해야하는지, 실제 서비스에서는 어떤 부분이 확인되어야 하는지 등을 종합적으로 정리하고 전체 스케줄링을 수정하였다.
오랜만에 작성하는 스케줄링 자료라, 정말 다시 한 명의 직업인으로써 새로운 삶을 시작하는 것 같아 감회가 새로웠다.
또, 4주 간의 기업협업을 마무리함과 동시에 user 웹을 구성하는 대부분의 레이아웃을 구현 완료하였는데, 생각보다 미디어쿼리가 복잡하지 않다는 걸 몸소 느꼈다. 다음에는 직접 구현할 수 있는 기회가 있기를.
Day 4
- 재정거래봇(일반) 기획 수정 반영 (일부 콘텐츠 삭제)
- 클릭된 버튼에 따라 다른 모달창이 뜨도록 구현
오늘은 기업협업의 마지막 날이라 오전 근무만 했다. 그래서 3시간 정도로 시간이 넉넉하지는 않았지만, 그 전날 추가로 요청이 들어온 내용을 반영하고 검토하여 1월부터 새로운 마음으로 업무 시작할 수 있도록 마무리를 잘 할 수 있었다.
한 주의 회고
4주 간의 기업협업. 정말 많은 걸 배우고 느낀 시간이었다.
다른 사람이 작성한 코드를 보고 해석하며 다양한 방식을 경험할 수 있었고, 함께 일하는 동료를 위해 유지보수가 쉬운 코드를 작성하려 항상 고민하였으며, 실제 사용자의 입장에 서서 사용하기 편리한 웹을 제작하기 위해 고민하였다.
기능을 구현하기 위해 아무 코드나 작성하기 보다는 구글링 해서 찾은 해결 방법이라도 이해하고나서 적용하려 노력하였으며, 이 부분이 실제 서비스를 개발하며 스스로 가장 성장했다고 느끼는 부분이었다.
앞으로 3개월, 이 프로젝트를 오픈베타 서비스까지 개발하게 될 텐데 항상 더 나은 방법을 고민하고 그를 통해 성장하는 프론트엔드 개발자가 되기 위해 노력할거다. 3개월 동안은 더 경험이 많은 개발자에게 수없이 질문하며 최대한으로 흡수하는 시간이 되기를!!!
