studying-together / study-http Goto Github PK

여러 작업을 각각 처리하기 위해 ThreadPool 을 만들어 사용한다.

ThreadPool 은 각각의 요청을 하나의 쓰레드가 담당해서 처리한다.

여러 요청이 동시에 들어왔을 때 문제없이 처리할 수 있을까?

장/단점에 대해 고민해보자

1. 좋았던 점
   먼저 나의 코드에 리뷰를 받는다는 점에서 다른 사람들의 의견을 들을 수 있어 좀 더 넓은 시각에서 자신의 코드를 바라볼 수 있는 기회였던 것 같습니다. 또 다른 사람의 코드를 리뷰 하면서 확인하고 공부하며 다시 한번 고민해보게 되는 시간이었습니다.

2. 아쉬웠던 점
   일주일이란 시간 동안 팀원 3명이서 시간을 배분하고, 여유 있는 시간을 맞추기가 쉽지 않았던 것 같습니다. 또 2일간 코드를 작성하고, 나머지 2일은 리뷰를 해야 하므로 일정도 타이트 하다고 느꼈습니다.
   무엇보다 데드라인만 있고 목표(어디까지 어느정도로 구현해야 하는지)가 뚜렷하지 않으니, 좀 더 어렵게 느껴졌던 것 같습니다.

1. 좋았던 점

• 스터디를 하며 코드를 작성해보는 시간이 좋았습니다. 직접 구현해보며 뭘 빼먹지는 않았을까 한번 더 자료를 확인해보며 더 효율있게 공부 할 수 있었던 시간인 것 같습니다.
• 자유도가 높아 마음껏 해볼 수 있어 재밌었습니다. 참 값진 시간이었습니다 ㅎㅎ

2. 아쉬웠던 점

• 이틀 동안 작업과 리뷰를 진행하니 시간이 너무 촉박하다고 생각이 들었습니다.

• PR 데드라인도 뚜렷하지 않아 모두가 리뷰에 참여하기 쉽지 않았습니다.

• 무엇을 어떻게 만들것 인지 픽스가 되어있지 않아 자유도가 높았지만 팀원들간 한번 쯤 청사진을 그리고 진행하면 더 효율이 좋을 것 같다는 생각도 들었습니다.

1. 좋았던 점

• 리뷰 시간이 좋았습니다. 리뷰를 통해 많은 개념을 알게 되었고, 어떻게 하면 좋은 코드, 좋은 구조가 될 지 생각할 수 있어서 좋았어요 👍
  리뷰를 할 때도 마찬가지로 다른 사람의 코드를 이해하려고 노력하고,
  코멘트를 달기 위해 공부하게 되서 좋았어요 ㅎㅎ
• 함께 작업을 하다보니 깃 컨벤션이나 주석 등 어떻게하면 다른분들이 이해하기 쉬울지 고민하게 되었습니다.

2. 아쉬웠던 점

• 시간이 촉박했던점이 아쉬웠습니다. 특히 평일이 끼면 시간이 촉박한 것 같아요..
• 처음에 팀끼리 구조를 잡는 시간을 가졌어도 좋았을것같아요!

1. 좋았던 점

• 클라이언트와 서버를 다시 만들어 보면서 놓치고 있던 부분들을 대해서 고민할 수 있었다.
  : 예 body 를 전달할 때 Content-Length 외에 chunked 방식은 무엇인가, header 에 어떤 정보가 필요할까?,
  socket 에서 readTimeout 과 connectionTimeout 을 어떻게 구분할까?

• 여러가지 깃 명령어들을 써볼 수 있었다.
  : rebase, git remote update 등등

• 맨땅에 만들기 때문에 기초적인 부분을 돌아볼 수 있었다.

• 이틀이라 그런지 작업량이 많지 않았고 그 덕분(?)에 새로운 코드도 해석하기 어렵지 않았다

2. 어려웠던 점

• 시간이 짧으므로 힘들다. 지치기도 한다. 욕심이 없다면 꾸준히 이어가기가 쉽지 않을 것 같다.
• 귀차니즘이 컸다. 의무적으로 한다는 것은 하고싶을 때 하는 것 보다 에너지를 소모하는 일이다.
• 상대방의 코드를 이해하려면 checkout 받아서 확인해야 했다. (하지만 장점이 될수도)
• 리뷰와 머지 시간이 애매하다.

좋았던 점

• 리뷰 프로세스가 좋았습니다. (리뷰 받은 내용에 대해 수정사항을 생각하며 다음엔 어떻게해야지~ 라고 생각할 수 있는 시간이 되어서 좋았습니다.(시간이 부족해서 수정은 못했지만..), 또한 어떻게 리뷰를 남길까 고민하는 과정도 좋았습니다)
• 팀원들의 코드를 보고 어떤 의도로 구현했는지 생각해보는 시간이 좋았습니다. (각자 개발했다면, 이렇게 자세히 들여다보진 못했을 것 같습니다!)

아쉬웠던 점

• 시간이 굉장히 짧다고 느껴졌습니다.. (다른분들의 차례일 때, 구현할 부분을 미리미리 생각해두어야지.. 라고 생각했지만 그렇게 되지 못했네요..)
• 방향성을 잡기 어려운 점이 있었습니다. 다른 분들과 방향성에 대해 같이 고민하는 시간이 더 있었으면 좋았을 것 같습니다.

P.S. 회고가 늦어서 죄송합니다ㅠㅠ

1. 좋았던 점

• 리뷰를 통해서 다른 사람이 구현한 코드를 보고 배울 점이 많았습니다.
• 내 코드도 리뷰가 된다는 점에서 좀 더 정성(?)을 쏟아서 구현하게 되었습니다.
• 릴레이 방식으로 코드를 작성한다는게 강한 책임감을 느끼게 해주는 것 같습니다.

2. 아쉬웠던 점

• 시간이 너무 부족했습니다. 좀 더 정성들여서 코드를 작성하고 싶었지만 절대적인 시간이 부족했습니다. (회사 퇴근하고 밥먹고 집 도착하면 최대 3시간 * 2일 = 총 6시간 => 제 기준에서는 공부하고 코드를 구현하기에 조금 빠듯한 시간이었습니다.)
• 리뷰를 하는건 가능하였지만 그 리뷰를 피드백해서 반영하는 시간이 너무 부족했습니다.
• 개발을 하면서 톰캣을 구현하는건지 서블릿을 구현하는건지 조금 헷갈렸습니다. 어느 정도의 가이드라인은 필요하다고 생각이 들었습니다.

와우

프로젝트 포크를 받아서 한 레파지토리 내에서 간단한 client와 server 간 TCP 통신 구현을 작업하고 있는데 클라이언트에서 데이터를 보내고 서버에서 클라이언트에서 보낸 데이터를 콘솔로 찍고 응답 메세지를 작성해서 클라이언트로 보내는데, 여기서 뭔가 교창상태에 빠져버리는 현상이... (왜 이런 현상이 발생하는지 잘 모르겠습니다...)

저와 같은 현상 겪으신분 해결책 공유좀 부탁드립니다. ㅜㅜ

서버에서 API 를 만들때 어떤 URL 이 좋을까 고민하게 된다.

RestfulAPI 란 무엇일까?

Java 에서는 네트워크 통신을 위해 Socket 과 ServerSocket 을 제공한다.
HTTP 의 특징인 Stateless 를 구현하기 위해 어떻게 처리해야 할까?

좋았던 점

• 팀 멤버분들의 코드를 보고 디버깅해보는게 확실히 공부가 되는 것 같아요. 혼자라면 쉽게 생각하지 못했던 방식도 알게 되고 같은 동작을 다르게 구현할 수 있다는게 흥미로웠어요.
• 리뷰를 통해 고려하지 못했던 부분에 대해 많이 알게 되어 좋았어요. 가볍게 생각했던 부분들을 되짚어 볼 수 있는 시간을 가졌고 이 부분이 공부가 많이 되었어요.
• 릴레이 형식으로 제가 작성한 코드를 다음 멤버가 작성하는 방식으로 진행하다보니 확실히 가독성, 코드 명료성등이 중요하다는 것을 느꼈어요. 나름 유지/보수하기 좋은 코드를 작성하기 위한 좋은 트레이닝법이지 않을까 생각이 드네요.

아쉬웠던 점

• 팀원들과 특별한 상의 없이 첫번째 순서로 바로 개발에 들어가서 어떤 방식으로 구현해야 할지 방향을 정하는게 어려웠어요. 방향을 잘 잡았으면 좋았을텐데 그러지 못해 아쉬웠어요. 다음엔 좀 더 도전적으로 시도해봐야겠다고 스스로 생각했어요.
• 방식에 대한 이해가 처음에 부족했어서 아쉬웠어요. 참고용으로 넣어뒀던 HttpClient나 내장 톰캣 라이브러리를 꼭 이용해야 하는 줄 알고 헷갈렸던 부분이 있어서 초반에 구현을 많이 못해 아쉬웠어요. (이 부분은 제가 오티 때 정신이 없어서 제대로 캐치를 못했기 때문이예요😭)
• PR 올리는 시간이나 리뷰 시간이 따로 정해져 있지 않아, 현준님의 역할이 없었으면 정말 큰일났을 것 같다는 생각이 들었어요. 촉박한 느낌이 들다가 한없이 늘어지기도 하고 이 부분은 좀 어려웠어요.

ps.공부가 많이 되는만큼 리뷰하는게 정말 쉬운 일이 아닌 것 같아요 !