이번 프로젝트를 하면서 느낀것인 너무너무 많다
아직 모르는것이 너무 많은데 하나씩 정리해보려고 한다
일단 7주간 프로젝트를 하면서 제일 중요하다고 느낀점
소통
솔직히 소통이 중요하다는건 지겹도록 듣고 실제로도 알고있다. 하지만 매번 프로젝트를 하다보면 소통이 정말 중요하다고 다시금 깨닫게 되는 것 같다.
우리팀의 에이스 갓태원님의 Git 강의를 참고 삼아 다음 프로젝트땐 야무지게 Git을 써보자
땅지원의 PMI 회고
Plus
- Git-Flow 적용이 재미있었고 많이 배워서 좋았습니다
- 프로젝트하면서 배포가 처음이였는데 Jenkins를 이용한 ci/cd 구축과 배포환경을 많이 이해할 수 있는 좋은 시간이였습니다
- 6명정도의 많은 사람들과 FE BE를 나눠서 개발한적은 처음인데 협업하는 과정에서 소통에 대한 중요성을 많이 배웠고 좋은 경험을 한 것 같습니다
- 에러코드를 많이 만나볼 수 있어서 좋았습니다
- HTTP state에 대해 많이 배워서 좋았습니다
- 팀원들이 맡은 역할을 책임감있게 수행해줘서 좋았습니다
- 코드를 보는 시각이 넓어진 것 같아 매우 좋았습니다
- Document를 적극 이용해볼 수 있어 좋았습니다
Minus
- 이 기술을 왜 사용하는지 확실하게 알지 못하는점(면접처럼 확실하게 말할때)
- 막히는 부분을 혼자 오래 고민한 점
- API 문서화를 적극적으로 이용하지 못한 것 같음
- 열심히 만든 다이어그램을 적극 이용 못한 점
- 개발 중 수정되는 부분을 모든 팀원들이 알지 못한점
- Jenkins CICD 구축에서 파이프라인을 더 탄탄히 하여 TEST까지 못돌린게 아쉽다
- Junit, log4j 등 개발에 필요한 라이브러리를 쓰고 싶었는데 못쓴게 너무 아쉽다
- Spring Security를 더 깊게 공부하고 적용해보고 싶었는데 겉햝기식으로만 해서 아쉬웠다
- FE, BE log & exception handling이 미숙한 점이 많아 디버깅이 오래 걸린게 아쉬웠다
- 개발하면서 만났던 이슈(에러 및 특이사항)을 틈틈히 기록하지 못한점이 아쉬웠다
- taskscheduler말고 sse나 websocket를 이용한 push 기능을 구현해보고 싶었는데 아쉽다
- redis - rdb connect를 못한점
- 개발하면서 현재 진행상황이나 상태를 회의 떄 더 자세히 공유 못한게 아쉽다
- 무중단배포를 못한점
- JPA 연관 관계 매핑을 못한점
- REST API를 확실히 이해하고 사용 못한점
Interests
- 웃으면서 개발할 수 있어서 좋았습니다
- 노트북 너무 무거워요
- 특화부턴 절때 반출안해
인프라
ai hub
하이버네이트
- MSA우선 팀의 현장조사를 통해 문제를 확인한 다음, 팀의 서비스 하나에 너무 많은 사람이 같이 붙어있어 관리가 어려워 나누고 싶거나, 기술 부채가 누적되어 일부를 조금씩이라도 뜯어서 고치고 싶거나, 서비스 모듈 간 기술 스택 자유도를 부여하고 싶다면 MSA 도입을 추천드립니다.
- 아니면 다른 것은 다 괜찮은데 배포 부담 만이라도 어떻게든 좀 줄이고 싶다 하신다면 위에서 소개 드린 배포 환경의 우선 도입을 추천드립니다.
쿠버네티스 vs 도커
AOP OOP
Intercepter filter
springsecurity
srp를 mvc에 적용하는법
단일책임원칙 SRP
Spring MVC말고 다른 디자인패턴도 많은데 우리가 한건 MVC가 정확히 맞을까
RESTAPI vs GraphQL
Junit
log4j
QueryDSL
Nginx
무중단배포
Spring Webflux → 알림 및 채팅
FireBase
websocket vs sse
Elastic Search
분산 아키텍처
단위테스트(유닛테스트) 꼭 하기
페르소나 분석
why what how
cookie localstorage
jpa domain vs entity
단위테스트(유닛테스트)
pmi 회고
다른조들한테 젠킨스 배워보고싶음
MSA
관리자 RequestParam vs PathVariable을 FE와 어떻게 맞출지 restapi 가격을 입력하라고했을때 int 초과 숫자를 입력하면 빠꾸시키는걸 프vs백 누가함
email.equals("") -> "".equals(email) NullPointerException 피하는법
Optional -> NullPointerException을 처리하기 가장 좋은 방법
okhttp in java(RESTAPI, HTTP 통신을 간편하게 사용할 수 있도록 만들어진 자바 라이브러리)
ResponseEntity는 ?(제네릭)으로 하지마라
Integer vs int의 차이는 null이 들어갈 수 있냐 없냐의 차이
엔티티 vs DTO의 차이
Service vs Controller Exception Handling
-> 애초에 Service Controller를 나눴다는건 각각의 목적이 있다는건데 Service는 특정 기능을 구현하는 목적을 가지고 있어서 에러 핸들링은 Service에서 하는게 맞다고 하심.
Controller는 단순히 Service를 호출하여 뿌려주기만 하면 되는 역할이다.
Spring MVC
-> 사실 Spring 자체가 MVC패턴을 기반으로 하고 있기 때문에 Spring을 한다고 하면 MVC패턴을 이용한다. 라고 보면됨
DTO에 관해서
-> User에 대해서 일부만 사용하여 만든 요청, 응답 클래스를 따로 만들어야할까?
컨설턴트님 : 어짜피 User라는 클래스를 이미 만들었기 때문에 최대한 이 클래스의 생성자를 이용하면서 중복코드를 줄이는게 맞다고 하심. 하지만 User + other class 라면 당연히 Request, ResponseDTO를 만들어서 관리하는게 좋다. 라고하심
개발원칙 OOP, SRP를 지키면서 개발한다는 의미
-> 사실 경력직을 뽑으려는 이유 자체가 이런걸 지키면서 개발을 할 수 있는 능력, 경험치를 가지고 있냐라는걸 본거같음, 신입 개발자일수록 이런 경험이 적을수밖에없을텐데 프로젝트를 하면서 관련 지식을 공부하고 흉내내보고 따라하는것만으로도 충분히 좋은 경험이 되고 '프로젝트를 하면서 어려움' 이런거에도 답변이 가능한 좋은 방법인 것 같음
'Backend > Spring' 카테고리의 다른 글
[Spring Security] BBKK에서 썼던 로그인 관련 정리 ★★★ (0) | 2023.04.13 |
---|---|
프로젝트 회고(BangBangGokGok) (0) | 2023.04.07 |
[Spring Security] SecurityConfig 작성 (version. Jiwon) (0) | 2023.01.25 |
[SpringBoot] CORS 설정 (0) | 2023.01.24 |
[SpringBoot] 빌드 및 배포 (0) | 2022.12.27 |