Week2 ‐ 멘토링

BE

• 진행상황 공유
  • CRDT와 소켓
    • 현재 CRDT와 소켓의 진행상황에 대해 멘토님께 전했습니다.
      • yjs와 socket.io 라이브러리를 사용해봤고, 코틀린에는 해당 라이브러리가 없어서 직접 구현중
    • CRDT와 소켓에 대해 깊게 공부해보면 좋을 것 같다는 조언을 받았습니다.
  • 배포 자동화
    • 배포 자동화는 경험해 보면 좋다고 진행하라고 조언을 받았습니다.
• Q&A
  • 디버깅과 코드 관리
    • Q. 코드가 많아질 경우 어떻게 찾아야 할지, 예외와 같은 알지 못하는 것들을 어떻게 찾아야 할지 궁금합니다.
    • A. 디버깅은 실시간으로 긁어서 올리고 찾아보면 되며, PR을 살펴보고 그때그때 대응하는 것이 좋습니다.
  • 메모리와 포트 관리
    • Q. 현재 모든 보드들이 메모리에서 관리가 될 것 같은데, 메모리 관리를 어떤 식으로 하면 좋을지 궁금합니다.
      • DB를 통해서 일정 시간이 지났을 경우 메모리에서 제거하고 DB를 통하는 방식으로 고민중
    • A. 메모리 걱정보다는 작게 만들어 놓고 잘 돌아가는지를 먼저 고민 해보는게 좋을 것 같습니다.
    • Q. 포트 번호정도는 Github에 올라가도 괜찮을 지 궁금합니다.
    • A. 포트에 대해서는 연습 단계에서는 아무것도 안 보이는 게 제일 좋을 것 같습니다. 습관을 만드는 것은 좋은 것 이니깐요.
• 추후 개발 방향 조언
  • 만약 실시간 처리가 힘들 경우 세이브 버튼을 만들어서 개발하는 것도 좋을 것 같다는 조언을 받았습니다.

Android

질답내용

• 뒤로가기 기능 어떻게 구현하면 좋을까요?
  • 삭제에 대한 뒤로가기만 구현하면 좋을 것 같음
  • 서버 영역이 큰 것 같아서 백엔드 분과 더 얘기해보기
  • 노드에 ID 값을 주면 이런 기능을 구현할 때 편할 것 같다
    • ex) 사용자 ID 별 스택을 만들어두고, 스택에 노드 ID를 넣어서 구분하기
• Line → Node → Text 으로 그리게 하고 있는데, 다른 더 좋은 방법이 있을까요?
  • 지금 구조도 괜찮고, 캔버스 특성상 원래 진짜 그림 그리는것처럼 이렇게 그린다.
  • 묶었을 때 관리하기 편하게 되는건 처음부터 완벽하게 설계할 필요 없으니 구현하다가 관리가 필요하다고 느껴지는 부분이 생길때 묶어도 괜찮을 것 같다
• 모듈화를 왜 해야하는지 잘 모르겠습니다. 해야할까요?
  • 필요하다고 느껴지지 않는데, 유행한다고 모듈 분리하는건 좋지 않다고 생각한다.
  • 모듈화는 언제든지 할 수 있으니 지금 필요하다고 느껴지지 않으면 당장 하지 않는게 좋을 것 같다.
  • 대신 패키지를 잘 분리해서 나중에 모듈화를 할 때도 손쉽게 할 수 있도록 해두자!
• 뷰와 뷰 그룹 중 어떤걸 사용해야할까요?
  • 뷰와 뷰그룹을 너무 다르게 생각안해도 될 것 같음
  • 뷰로 해보시다가 뷰그룹의 기능이 필요하면 그때 생각하기
• ConstraintLayout을 사용한 구조 어떤지
  • 보통 커스텀 뷰를 할 때 프레임 레이아웃을 많이 사용함
    • 각 레이아웃의 차이를 알아보고, 왜 FrameLayout을 많이 사용하는지 고민해보기
    • 어떤 레이아웃을 선택하는지도 되게 중요함
    • 구글링 하면서 다른 사람들 코드 많이 보기!
• 커스텀 뷰의 스케일 조정
  • 노드가 많아지면 scaleX 값 등을 조절해서 해결하기
  • 커스텀 뷰의 스케일을 조정했을 때 도화지 안에 있는 노드들의 크기가 변하는지 먼저 확인해보고, 만약에 변하지 않는다하면 노드들도 조정을 해야함
  • 직접 테스트 해보기
• dp, px 클래스를 만들었는데 더 좋은 방법이 있을지
  • 클래스를 왜 만드는지에 대해 고민해보기.
  • Class, 프로퍼티, 최상위 함수 각각을 어떨때 사용해야하는지 명확히 하자
• invalidate를 너무 자주 호출하는 것 같다
  • 이부분은 다 구현하고 고민해도 늦지 않다
  • 그리고 화면을 갱신할 때 invalidate와 requestLayout이 있는데, 지금 화면을 갱신하려면 어떤 작업을 해야지 갱신할 수 있는지 고민해보고 잘 선택하기
    • 캔퍼스가 어려운 이유중 하나가 이거이기도 함.

추가 조언

• 검색할 때 android ~~ github 로 검색해서 다른 사람들 코드 많이 보기, star가 많은 순으로 보는 것도 좋음
  • ex) android mindmap github
• 개발에 정답은 없으니 자기가 생각했을 때 이게 맞다고 생각하면 개발을 하고 타인의 개발 코드를 봤을 때 더 좋은 방법이 있으면 개선하면 됨

공통 마지막 조언

• 기획이 잘 잡혀있으므로 어떤 것이 더 중요한지를 판단하고, 구현이 완료되면 좋은 포트폴리오가 될 것이라고 조언을 받았습니다.
• 다들 잘 하고 있으니, 모르는 것이 많아도 주눅들지 말고, 잘못된 것을 말해도 괜찮다고 말하였습니다. 보정해 나가는 것이 중요하다고 강조하였습니다.