분류 전체보기
-
20221204 TIL 포기하지 않고 조금씩 앞으로 나아가자TIL 2022. 12. 4. 22:20
수료가 가까워짐에 따라 고민도 늘고, 나의 실력에 대한 회의감이 들고, 약간의 슬럼프가 온 것 같다. 어느 정도 마음을 다잡고 몰입이 엄청 잘 되는 날이 하루 지나면 그 다음날부터 컨디션이 살짝 안좋은 날들로 이뤄진 주기가 반복이 되고 있다. 작업량이 불규칙하면 작업 계획을 세우기가 매우 어렵다. 따라서 작업량을 어느정도 일정하게 유지할 수 있도록 만드는 것이 다음 주의 나의 중요한 미션이다. 너무 몰입이 잘 되는 날이더라도 마감 직전이 아니라면 9시 정도에 마무리를 하는 것이 그 다음날 컨디션에 영향을 덜 줄 것 같다. 그래도 내 자신을 칭찬해준다면, 컨디션이 많이 안좋은 날에도 코딩을 많이 하지는 않았지만 쉬지는 않았다는 점이다. 최대한 어제의 나보다 조금이라도 발전한 오늘의 나가 되도록 하루를 보내..
-
20221203 TIL 테스트의 독립성을 어떻게 보장하면 좋을까?TIL 2022. 12. 3. 17:41
메가테라 과정을 수강하면서 가장 신기했던 부분은 프론트에서 (전역) 상태 관리를 다른 어떠한 외부 라이브러리 없이 구현을 했다는 점이었다. 구독 형식으로 listener를 등록해두고, store에서 상태를 바꾼 뒤에 publish를 하면 구독하고 있는 컴포넌트들이 리렌더링되면서 바뀐 상태가 반영되는 방식이다. 이를 활용하면 객체지향적으로 상태 관리를 할 수 있다는 장점이 있는데, 사용을 하다가 테스트가 조금 이상하게 동작하는 것을 발견하게 되어서 분석을 해봤더니 이 방식을 사용하면서 테스트를 독립적으로 돌리기 위해 고려할 점이 있다는 것을 알게 되었다. 일관적인 상태 관리를 위해 모든 컴포넌트가 동일한 store를 사용해야하기 때문에 싱글톤 방식으로 동작하고 있는데, 이 싱글톤 방식으로 동작한다는 것이 ..
-
20221202 TIL 더 나은 형상 관리를 위하여TIL 2022. 12. 2. 18:05
Git을 써온지도 벌써 1년이 다 되어간다. git을 다루는 것은 이제 더이상 두렵지 않아졌고, git과 관련된 도움을 요청받았을 때 대부분의 상황을 해결할 수 있는 수준이 되었다. 하지만 git branch이름, git commit 내용을 잘 작성하기는 아직도 어려운 것 같다. 과제를 진행하면서 branch명과 commit내용을 작성하다가 이렇게 간단하게만 작성을 해도 되는 것일까, 더 잘 작성하는 방법은 없을까 고민을 하다가 컨벤션을 찾아보고, 더 나은 커밋을 작성하는 방식을 골라보았다. 먼저, 깃 브랜치명은 '간략한 설명'으로 작성하기로 결정했다. 지금은 티켓을 만들고 있지는 않기 때문에 이 브랜치에서 할 업무에 대한 간략한 설명을 하이픈 '-'을 이용해서 작성하는 방식을 택하기로 했다. 티켓을 작..
-
메가테라 15주차 주간회고회고 2022. 12. 2. 18:02
이번 주는 간소화된 쇼핑몰을 만들어보는 레벨테스트 주간의 첫 주차였다. 프론트엔드부터 백엔드까지, e2e테스트, 유닛테스트를 모두 작성하고, TDD방식으로 작업을 진행했다. API설계를 끝내고, e2e테스트는 모두 작성을 완료하고 구현을 시작했을 때 처음부터 제대로 모든 것을 다 하려고 하다보니 진행 속도가 느렸고, 해야되는 일의 양에 압도되어 의지도 저하되었었다. 그래서 최대한 업무를 쪼개고 한 번에 완벽하게 구현을 하려고 하기 보다는 수정이 조금 있더라도 몇 단계에 걸쳐서 작업을 진행했다. 예를 들면 회원 가입 폼을 구현할 때 다뤄야하는 유효성 검증 내역이 많은데, 유효성 검증 없이 일단 어떤 값을 입력하든 회원가입이 되게끔 작업을 진행하고 나서, 유효성 검증 로직을 추가하는 방식으로 진행했다. 처음..
-
20221201 TIL 내일의 계획을 오늘 밤에 세우기TIL 2022. 12. 1. 18:01
일을 진행할수록 해야될 일이 명확해지는 것 같다. 이때까지는 작업을 진행하기 전에 작업 계획을 세우고, 작업을 진행하면서 작업 내역을 작성하고, 작업 도중에 혹은 작업이 끝나고 나서 깨달은 점 및 아쉬웠던 점을 작업 회고에 남기는 방식으로 진행하고 있었는데, 아침에 와서 '내가 뭘해야되지?'를 고민하면서 시간이 꽤 소모되었었다. 그런데 어제는 일을 마무리하는 시점에 그 다음에 해야할 일이 너무나 명확해서 오늘의 작업 계획을 어제 세우고 갔다. 그랬더니 하루동안 무엇을 할지가 매우 명확해져서 작업을 효율적으로 할 수 있었다. 그리고 어제 내일의 할 일을 계획하면서 생긴 고민되는 부분이 있었다. 제품 상세 페이지를 구현하기로 계획을 했는데, 제품 상세 페이지에서 항상 처음에는 구매 수량이 1로 초기화가 되어..
-
20221130 TIL 인생 최초로 크롤링을 해보다TIL 2022. 11. 30. 14:18
이번 과제에서는 카카오 선물하기를 비슷하게 만들어보아야 한다. 쇼핑몰은 상품들을 파는 곳이기 때문에 상품 정보를 등록해야 하는데, 페이지네이션을 제대로 구현해보기 위해서는 적어도 81개의 상품이 필요했다. 그런데 81개의 제품의 이름, 제조사, 가격, 이미지 주소를 모두 한땀한땀 모아서 넣어주는 것이 너무나 소모적으로 느껴졌다. 그래서 이제까지 도전해보고 싶었으나 하지 못했던 크롤링을 이용해 데이터를 모아보았다. 확실히 html과 css, http를 배우기 전에 크롤링을 접했을 때보다 이해가 되는 부분이 많았고, 원하는 정보를 원하는대로 획득할 수 있었다. 크롤링을 막아둔 웹사이트가 아니라면 html, css지식만으로도 쉽게 원하는 정보를 습득할 수 있었다. from bs4 import Beautiful..
-
20221129 TIL UX를 고려하자TIL 2022. 11. 29. 16:15
과제를 진행하는 중에 갑자기 궁금해졌던 부분이 있었다. 프론트와 백을 나누는 기준은 무엇일까? 프론트에서 비즈니스로직을 어디까지 다루는 것이 적합할까? 언제 백엔드에서 데이터를 받아와서 프론트에 보여주고, 언제 프론트 내부 로직만을 이용해서 화면에 보여줄까? 사용자 경험을 중심으로 생각하면 이에 대한 답을 찾을 수 있었다. 사용자 경험을 우선시 했을 때 바로바로 보여지는 게 중요한 부분은 프론트에서 보여주고, 백엔드와 동기화가 중요한 주문 결과 등은 서버에서 받아온 값을 보여주는 것이 바람직하다. 사실 조금만 고민해보면 당연한 부분이었던 것 같다. 내가 사용하고 있는 서비스들을 중심으로 생각을 해보면 질문 없이 스스로도 답을 찾았을 수도 있었을 것 같다. 예를 들어 예매 사이트에서 특정 자리를 선택을 했..
-
20221128 TIL 유효성 검사를 어떻게 하면 좋을까?TIL 2022. 11. 28. 17:41
회원가입, 로그인이 포함된 프로젝트를 진행하면서 유효성 검사를 어떻게 하면 좋을지에 대한 고민이 생겼다. 프론트엔드에서 글자수 제한 등 프론트가 백과 소통하지 않고 체크할 수 있는 부분은 큰 문제가 없었지만, 중복 id체크 등은 프론트 자체적으로 검증을 할 수 없고, 서버와 통신이 필요했기 때문에 어떻게 처리를 해서 에러메시지를 화면에 보여줄지 고민이 되었다. 저번 프로젝트를 진행할 때는 form data를 서버로 넘겼을 때 errorDTO를 사용해서 에러 코드를 받으면 에러 코드에 해당하는 메시지를 프론트에서 보여주게끔 작업을 했었다. 에러메시지를 서버에서 보내준 것을 프론트에서 화면에 그대로 보여주게 된다면 메시지를 수정하고 싶을 때마다 서버에서 수정해야되기 때문에 에러메시지를 사용하기 보다는 에러 ..