[취업준비일지] - 61 - 원티드 인턴십 1일차

인턴십 세션을 듣는 중에는 따로 회고를 분리할 생각을 하지 않았지만
생각보다 팀으로 분할된 다음 진행되는 내용이 많아 
회고를 따로 진행하게 되었다.

2시부터 5시30분정도까지 수업을 듣고
모여서 회의를 7시30분정도까지 진행한 다음
23시 30분에 모여서 리뷰를 하기로 했다.
(그전에 7개의 코드 분석..)
잘된점, 개선점, 궁금한점
인증 인가, crud, 폴더구조, 가독성, 변수명, readme, commit, history 등
각 레포마다 1개 이상 찾아오기로 결정되었다.

아래는 개인마다 적은 것으로  
정보보호?를 위해 이름을 제거했으며 
시간상 다 제대로 보기 쉽지 않아
아래로 내려갈수록 잘된점, 개선점 등이 부족한 것을 볼 수 있다.
또한 발표 내용을 보며 추가적으로 생각할 점 또는 알게된 점이 있다.

 

-A
 잘된점 - ts사용, refactor(리팩토링),최적화(리렌더링 감소),eslint, prettier, not-found 페이지를 통해 이동시키는 부분, 변수명이 깔끔
 로그인 실패 결과에 따른 내용 출력(없는 회원)
 개선점 - 리다이렉트 시도 안됨(로그인 실패)
 궁금한점 - '@'를 처음 봤는데 절대경로 설정이라는 부분
          useDebounce가 작동이 제대로 되는지 궁금(set이 대기중일 때는 의미가 있나 궁금하다)
          
테마들 모아서 넘겨주고 사용하는 것 좋아보인다.(색 사이즈 등)
svg 포인터 커서로 svg에서 설정
router폴더 새로 생성 후 저장시 거기에서 따로 경로 관리
useDebounce 사용으로 최적화 시도
todoProvider로 children 내보내는 것
React.memo로 todo 리렌더링 방지


-B
 잘된점 - 컴포넌트 분리
 개선점 - 새로고침 시 Page Not Found 출력, 성공 alret 출력(리다이렉트시에도)
 커밋 횟수가 분할에 비해 적어보이는 점
 궁금한점 - 리액트 메모 최적화 어떻게 했는지


-C
 잘된점 - 폴더구조, 커밋, 타입스크립트
 개선점 - 로그아웃이 없음, 이메일 유효성이 부족, .env 노출, 글 관련 렌더링 콘솔찍힘
 궁금한점 - 
 
todoReducer를 통해 기능들 관리하는 부분


-D
 잘된점 - readme 기능 설명들(좋은건지 아닌지는 모르겠다), 블로그를 통한 구현내용 설명
 개선점 - 배포페이지가 없어서 테스트가 불가능, 폴더구조가 일반적 형태는 아닌 것 같음, 불필요한 app.css파일
 궁금한점 - gitignore에 env파일이 여러개 보이는데 설정을 어떻게 하셨는지 궁금

유효성을 따로 빼두는 것(각종 유효성들을 모아두면 좋을 것 같다)


-E
 잘된점 - 에러페이지 생성으로 에러핸들링
 개선점 - 유효성, 유효성 안내 위치
 궁금한점 - 

axios 사용하는 부분을 통합해서 가독성을 높인다는 의견(동의)
경로 "*"을 통해 에러페이지가 나오게 설정(try / 실패했지만 좋은 시도)

 
-F
 잘된점 - 폴더구조, ts
 개선점 - 
 궁금한점 - Auth로 감싸는 것에 대한 추가적인 호기심
          로더를 사용해 async, await로 투두리스트를 받아온다(왜?)

polished를 통해 밝기에 따른 색 변경?
에러관리는 전역 에러 관리를 Route 태그 단계에서 지정
Auth로 감싸진 페이지?는 권한 확인하게 만듬
인터셉터 등으로 refresh등 관리하는 것(없지만 좋은 아이디어)
로더를 사용해 async, await로 투두리스트를 받아온다


-G (내 코드 관련 피드백)
회원가입 시 비밀번호 확인이 없어 잘못된 비밀번호로 가입할 경우 찾을 수 없다.
중복되는 부분이 많이 있어 통합하는 과정이 있으면 좋을 것 같다.
(후순위라 내용적으로 유사함이 많아 빠르게 지나갔다)



보일러플레이트 작성을 한 다음 진행하자, 시행착오 문제 및 시간부족이다
설계 제대로 해서 해야 빠르다, 구현은 해봤으니 고르기만 하자 등의 의견이 있었고
라이브러리, 코드리뷰 먼저 진행하기로 해서 코드리뷰를 끝내고
내일 오후 3시에는 기준점에 따라 7가지를 모두 채워야 한다.

회의 전 기준점에 들어갈 최고의 코드를 찾아오는 것인데 
타입스크립트 사용 여부 등 짚고 넘어갈 것들이 많다.

또한 리드미, 커밋로그에 대한 부분도 문제였다.



1.squash를 통해 커밋을 합쳐줄 수 있기 때문에 굳이 기능적으로 분할해서 하지 않고 그룹으로 쪼개 a-1, a-2, a-3등으로 작업 후 a로 통합할 수 있다.


2.eslint를 사용할 경우 npx eslint .(현재 폴더)를 통해
현재 발생한 모든 에러들을 확인할 수 있다.(eslint의 기준 에러)


3.eslint를 효율적으로 사용하려면 npx eslint --cache로 처리할 수 있다.
그러면 변경된 부분만 검사를 진행한다.
이를 통해 생성된 eslintcache는 gitignore에 넣어줘야 한다.(로컬환경 주소기 때문에)


4.prettier 또한 npx prettier --write --cache를 통해 캐시처리를 할 수 있다.


5.이를 계속해서 치기 귀찮을 경우 package.json의 scripts에 추가할 수 있다.
{"format" : "prettier --write --cache .",
 "lint" : "eslint --cache ."}
 
 
6.웹팩 설정에서 파일의 경로를 수정해 '@'를 지정한 다음 앞 경로부분이 대체된다. 


7.TCP 통신에서는 reliable network를 보장하기 위해 아래의 4가지를 해결해야 한다.

손실 - packet이 손실 위험성
순서 바뀜 : packet이 unordered로 들어오는 현상
Congestion : 네트워크 혼잡
Overload : 지나치게 많이 들어오는 문제

이를 해결하기 위해 흐름제어와 혼잡제어를 사용한다.

 

8.흐름제어를 하는 이유는 
한번에 처리 속도보다 더 큰 데이터가 쏟아질 경우
처리되지 못한 데이터가 쌓여 문제를 발생시킬 수 있다.
또한 저장공간 초과의 데이터가 손상될 경우
계속해서 받아와야 할 수 있는 등의 추가적 문제도 발생한다.

대표적으로 이를 해결하기 위한 두가지 방식이 있는데

Stop and Wait이라는 방식은
패킷마다 처리가 된 경우 다음 데이터를 달라고 신호를 보내는 방식이고

Sliding Window라는 방식은 
stop and wait 형태를 점에서 직선으로 늘린 것 같은 형태로
수신측이 받을 수 있는 최대 사이즈 만큼의 규모를 유지하며
규모 내에서는 제한없이 전송하고
만약 지정 규모를 벗어나려 할 경우 중단한 다음
수신완료 확인이 된 데이터들을 
규모측정에서 제외시켜 다음 데이터를 보내는 방식이다.

1차원적(점) 단위의 처리 응답 대기 시스템은 stop and wait
2차원적(선) 단위의 처리 응답 대기 시스템은 Sliding Window라고 볼 수 있다.


9.혼잡제어는 양방향의 소통 문제를 해결하기 위한 흐름제어와는 다르게
대규모 네트워크에서 지나치게 많은 데이터가 
하나의 통로에 쏠릴 경우를를 제어하기 위한 방식이다. 

해결 방식에는 아래와 같은 4가지가 있다.
AIMD(Additive Increase / Multiplicative Decrease)(덧셈식 증가, 곱셈식 감소)
 패킷을 1개씩 늘려가며 보내고 실패/지연시 전송 속도를 반감시킨다.
 패킷 수용치까지 도달하는 시간까지는 비효율적이며
 혼잡해진 다음 대처가 된다는 단점이 있다.

Slow Start (느린 시작)
 패킷을 2배씩 늘려가며 보내고 실패/지연시 패킷 수용치를 찾기 위해
 이전 전송치(현재%2)에서 1개씩 늘려가는 방식으로
 규모가 클수록 AIMD보다 한계치를 만나는 속도가 기하급수적으로 빠르다

Fast Retransmit (빠른 재전송)
 순번이 맞지 않을경우 보내는 ACK 패킷을 받을 경우
 일반적으로는 재전송을 해주지만
 패킷이 중복되게 3번 쌓이는 경우 
 window size를 줄이고 손실된 패킷을 재전송해준다.

Fast Recovery (빠른 회복)
 시작과 관련없이 작동하는 방식으로
 혼잡이 발생할 경우 Slow Start처럼 반감 후 패킷을 하나씩 늘려간다.





(1).백준 5988 홀수일까 짝수일까는 여러 테스트케이스 중 홀짝을 구분하는 문제로

특이점은 10^60까지 가는 큰 수치였다.

Number가 아닌 BigInt를 사용한 다음 %2가 아닌 %2n으로 해결했다.

let input = `2
1024
5931`.split('\n').map(BigInt)

let result = []

for(let i = 1 ; i < input.length ; i++){
    if(input[i]%2n) result.push('odd')
    else result.push('even')
}

console.log(result.join('\n'))