3주차 멘토링

2주차 프리징 코드에 대한 리뷰

BE

• env로 변수하는 것 좋다 (칭찬)
• 리턴할 때 false로 할 것인지, null로 할 것인지 통일하자.
• 상태를 변경시킬 때 immutable한 것이 좋다.
• dev/prod 나눠서 하는 것이 좋다.
• core js는 dev가 아닌 그냥 dependency로
• 콘솔로그 제거하기

FE

• instance 변수 네이밍에 대해 생각해보기
• attachToRoot를 좀 더 재사용성을 높여보자
• 메소드를 작게 쪼개고 있어 좋다.
• !important 지양하자.
• API 에러처리는 어떻게 할 것인가?

3주차 코드리뷰

FE

• 기존 createElement()에서는 바로 div 태그를 생성하는데 태그 타입을 받아서 생성하도록 하자.
• 매직넘버 최소화 하기
• class를 추가할 때 함수에 클래스 파라미터를 받도록 하자.
• 변수 이름 변경하기 (동사가 아닌 명사로!)
• 메소드 체이닝
• addClass가 배열로 파라미터를 받을 수 있도록 하자 -> 오늘 작업하기! 까먹음!!!!

12월 3일 멘토링

멘토링 전 질문 생각해보기!

• a. 제가 작성하지 않아서 내용을 모르는 코드들이 점점 늘어나기 시작했습니다.
  • 일단 PR 단위가 큰 것도 한 몫 하는 것 같습니다.. => Agree
• b. 일을 분배할 때 다른 사람과 코드가 겹치지 않게 해야하나요?
  • 이것도 PR 단위를 쪼개면 더욱 해결될 것 같다고 항상 생각중입니다. ㅋㅋ ㅋㅋ저도요 222222222222
• c. WebRTC 사용 시 https가 필요한데 local이나 배포에서 어떻게 환경구성해야될지 솔직히 좀 막막해요?? => So hard... 아쉽네요...
• d. alert 말고 다른 방식으로 사용자에게 전달할 수 있는 좋은 방법이 있을까.
• e. CSS class와 inline style이 너무 혼재되어 사용되고 있는데
  • CSS class 내용을 실행 중간에 바꿀 수 있나요...
• 크롱님 후드집업 예쁘네요.. (정보..) => 네이버를 가야 가질 수 있음
• f. 추가작업을 할 때 한 팀원이 다 해버리게 되면 괜찮을지

멘토링 내용 🦖

• 개발도 중요하지만 규칙을 잘 지키고 '일을 잘 하는 사람'이 되어야 한다! (적당히..!)
• a. 팀이 코드를 이해할 수 있는 방법 중 하나는 페어프로그래밍이기는 하지만, 이런 이유로 하기는 어렵다. 어쩔 수 없다... >> 교차로 개발, 하던 일을 받아서 마무리하는 것도 하나의 방법! (어려움)
  • 현업에서는 모르면서 산다. 이 정도도 낫밷~
  • PR 단위를 쪼개는 것이 좋다. 의식해서 작게 보내도록 노력하자. 배포시간이 정해지더라도 작게 하는 것을 지키는 회사들도 있다. (악덕 회사...?) 어떤 것을 우선순위에 둘 것인가...
• b. 원래는 같은 파일을 잘 수정하지 않는다. 대화를 통해서 해결한다.
  • 파일을 더 쪼개는 것도 좋은 방법
  • 애초에 그런 상황을 만들지 않는 업무 프로세스를 채택하는 것도 방법~..
  • 페어프로그래밍..?
• c. 노하우는 없다. 로컬에서도 가능은 할 것 같음. 삽질 열심히 하기~
• d. 써보고 편하다 싶으면 해도 됨~ 요즘 alert 는 보기 힘들다.. 강력한 메세지일 때는 괜찮음
  • 모달 창을 써볼까요!? 아니면 메인으로 리다이렉트하고 오리가 말하는 것처럼 할까요? '이런, 코드가 잘못됐군요~ 유감입니다.'
• e. 없다. inline으로 한 거는 inline으로~ JS로 CSS 수정은 안된다.
• f. 공유를 잘 하자. 기능에 대한 경험을 같이 해야한다 싶으면..? 지금은 공유도 하고 리뷰도 하면 오케이~
  • 해 본 내용을 팀원들과 잘 공유하기
• 내일 데모 목표를 정해보기
• 일주일짜리 코드리뷰 하는 팁 : 다 못 봄. 의도는 모른 채 코드리뷰...⭐️ 그래도 짬바가 있어서 가능