프로젝트를 위한 마음가짐

프로젝트를 위한 마음가짐은 어떠한 것일까?
방학동안 혼자나마 가볍게 생각해봤다. 정답이 아니고, 단순 내 생각일뿐

프로젝트의 소프트스킬

처음에는 컨벤션 및 논의할 부분을 생각했다.
( List 를 반환하지 않고 무조건 DTO로 래핑하고, 커밋 메시지에 괄호및 상세 내용을 적어야 하는가 등등에 대해서 )

하지만, 컨벤션이나 기술이 프로젝트를 시작하지도 못하거나 팀원간 상호 소통이 없을때 의미가 있을까?
특히나 너무 백엔드 적인 부분에서 마음가짐만 생각했는거 같다.

결국, 보지 못한 프론트엔드 or 안드로이드 분들과 협업을 하는 것인데
기술적인 요구사항은 1순위가 아니라고 생각한다.

개학하고 그 다음날까지 바로 주제를 제안해야 해서 매우 빡빡한 일정이지만
상대방들이 누구인지와 프로젝트에 대한 열정 및 목표에 대해서 충분히 알아가는 시간이 있었으면 좋겠다.

길다면 길고, 짧다면 짧은 레벨3,레벨4 동안 같이 해야할 사람들인데
좋은 인연이자 같이 프로젝트를 완수해나가는 좋은 동료들이 되려면
프로젝트에 지장이 가지 않게 너무 느리지는 않으나, 서로에 대해 꾸준히 유대를 쌓아가도록 노력해야 겠다.

프로젝트의 주제

프로젝트 주제를 어떤 것을 할지, 어느 정도의 규모를 해야할까 생각을 방학동안 했다.

내가 내린 결론은
20명 정도의 트래픽이라도 발생시킬 수 있는 필요한 사람들을 타겟으로
꾸준히 요구 사항을 반영 & 추가해나가는 프로젝트를 만들고 싶다.

레벨 1,2 를 해오며 가장 크게 느낀점은
기술이 어떠하고, DDD가 어떠하고, 패키지 구조가 어떠하고는
트래픽과 요구사항 확장을 해나가지 않는한 의미 없는 우물 안 개구리라는 것이였다.

간단한 프로젝트인 방탈출에서 요구사항 추가&사용하는 기술 변경을 마주쳤을 때도
수많은 테스트 코드가 깨지고, 서비스 구조가 기존과 흐트러지고 탁상공론은 의미없다.

트래픽도 위의 내용과 마찬가지다.
사용자가 늘어날 것을 대비해서 카프카를 도입하고, 비동기를 도입했다고 말한들 트래픽이 없으면 이 모든게 무슨 의미일까

그렇기에 조금 주제가 별로더라도, 이미 있더라도 사용자를 이끌어 낼 수 있다고 생각하면
주저하지 않고 그 주제를 하자고 설득할 것이다.

프로젝트의 코드

컨벤션을 어디까지 정해야 할까에 대한 내용이다.

우테코에서는 절대답지의 컨벤션이나 코드 스타일을 가르쳐 주지 않았다.
강의에서나 리뷰나 방향성을 제시해주는 것이 다였다.

사람들마다 자신이 생각하는 코드 스타일 & 테스트 스타일 & 패키지 스타일 등 천차 만별일 것이다.
이것을 교정하는게 말이나 될까 ( 나한테도 누가 뭐라 하거나 건들면 니가 뭔데? 라고 생각부터 하겠지 )

1. 그래서 최대한 interface 를 만들어 가려고 노력해볼 예정이다.
   최소한의 리미트나 지켜야 할 것만 걸고 그 안에서는 다양하게 + 자신이 하고 싶은대로 구현하는 식으로.

프론트와의 통신 일관성을 위해 List<DTO> 이면 이를 래핑해서
DTO를 하나 더만들어서 넘깁시다!
EX) List<ReservationResponse> -> ReservationsResponse

2. 추가적으로, 팀원들이 모두가 괜찮아 한다면 코드 리뷰를 꼭 하고 싶다.

더 나은 퀄리티를 + 일관성 있게 계속 이끌어 나갈 수 있을거라 믿기 떄문.
물론, 부담을 주거나 일종의 스트레스로 느껴지지 않게 잘 배분해나가야 할 거 같다.
( 1주일에 한번 정도 가볍게 코드 리뷰나 페어로 그냥 서로에게 리뷰 정도 )

---

프로젝트의 퀄리티나 아이디어 보다
내가 보여줄 수 있는 + 제어할 수 있는 프로젝트 중 느낀점이나 현업하는 개발자로서의 나를 찾을려고 노력할 거 같다.

서비스를 런칭하거나 유지보수 할 수 있다면 너무나 큰 행복이겠지만
제어할 수 없고 미래 지향적인 것 보단 내가 챙길 수 있는 것을 위주로 프로젝트를 해나가고 싶달까

많은 경험과 깊은 유대를 그리고, 서비스를 만들어가는 행복을 느낄 수 있는 내가 되도록 노력하자