Zero : 리펙터링, clean코드 같이 기본 베이스를 다질 수 있는 스터디를 진행하는 것도 좋아보입니다.

스프링이나 특정 프레임워크 같은 부분은 숙련도의 차이가 다양하여 비교적 숙련자들에게는 안타까운 상황이 많이 생기는 것 같아요.

Alan: Design Pattern 을 하면 좋을 것 같습니다. 리팩터링, 클린 코드도 좋지만 두 그보다 초보자가 스터디 하기에 조금 더 명확한 주제라고 생각 했습니다. 학부때 혹은 다른 개발 도중에 스쳐지나간 것들을 한번 정리할 수 있는 기회도 될것 같아 보입니다.

• 장점
  1. 모두가 다 참여할 수 있다: 언어의 제약이 없고 지식의 기반이 얕던 깊던 생각해볼 수 있는 요소가 많다.
  2. 학부 과정 혹은 개발 과정에서 한번쯤은 부딪혀본 문제들이 많기 때문에 감을 잡지 못하는 경우가 적을 수 있다. (너무 막연하기만 한 주제는 토비 스터디에서 생긴 문제가 또 발생할 것 같아 보여요..)
  3. 전반적인 개발의 기초 지식이 될 수 있다. 또 기존에 알고있었던 부분을 정리하면서 반복할 수 있는 기회가 될 수 있다.
• 단점
  1. 이론 중심으로 진행이 되면 조금 지루하게 느껴질 수가 있다. (도서를 선정하여 해당 과정을 리드하며 진행하면 스터디 때 실습을 병행할 수도 있을것 같아 보입니다.)
  2. 정답이 없는 문제를 다루기 때문에 끝없는 논쟁으로 빠지게 될 수도 있다.
  3. 너무 공부를 잘 했을 것 같은 분들에겐 지겨운 주제일 수도 있다.

다음 스터디부터는 스터디의 호흡을 스프링 실습 기간 처럼 시작부터 종료까지 기간을 어느정도 정하고 진행해 보는것이 좋을것 같습니다. 끝이 너무나도 멀게만 느껴지고 막연하게만 느껴진 초반 스프링 스터디보다 실습 + 목표가 명확했던 과정이 조금 더 좋았던 것 같습니다.

kong

좋았던 점

• 실무에 필요한 지식을 스터디 해서 좋았습니다.
• 각 세션별로 주도하는 분이 있어서 좋았습니다.

아쉬운점

• 재택 근무로 인해 스터디가 지연된 점이 아쉬웠습니다.
• 각자 해야할 Task 가 많아서 참여율이 떨어진 점이 아쉬웠습니다.
• 팀원 별로 학습에 대한 이해도가 다른 점이 아쉬웠습니다.
• 중도 참가라 초반에 진행에 어려움이 있었습니다.

개선 방법

• 퇴근 후에 하지 말고 점심 시간에 진행하는 것
  • Task가 많더라도 점심 시간에 진행하는 것은 부담이 덜 하고 개인적인 스케쥴로 빠지는 것을 방지할 수 있어서 점심 시간에 진행하는 것이 좋을 것 같습니다.
• 교재가 있으면 좋을 것 같습니다.
  • 중간에 참가하거나 스터디를 일시적으로 참가하지 못해도 교재를 정해서 하면 복귀/참가 하는데 수월할 것 같습니다.