1. 문제와 해결방법 **(과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제)** 1) 이번주에 겪은 문제는 환경변수에 따라서 다르게 CD 하는게 이해가 안되었다.application.yml을 환경별로 어떻게 다르게 하여 CI/CD 하는지 이해가 안됨.=> 해결방안 : secret에 환경별로 application.yml을 저장하고, github-action 코드에서 빌드시마다 src/main/resources 폴더에 생성하여 프로젝트를 빌드하는 방식으로 진행 예정. 2) github secret 사용법을 이해하지 못했다어디에 application.yml을 넣는지 등등=> 해결방안 : github secret에서 application.yml을 base24 인코딩 하여 사용하는 방식으로 해결 예정https..
[낙관적 락 vs 비관적 락] 동시 요청 중 한개만 성공해야 하는 경우에는 낙관적 락을 사용한다.상황에 따라 다른데, 재고 수량 차감하는 상황에서 2개의 요청이 들어왔을 떄 하나를 실패시키는게 맞나?아니다 두 요청을 모두 처리하는게 맞기 때문에 이건 낙관적 락보다는 비관적 락.반면에 좌석 예약은 한개의 요청은 떨어트려야하기 때문에 낙관적 락이 유용. 낙관적 락 => 1개의 요청만 성공시키고, 나머지는 다 실패시켜도 괜찮아. 이러면 낙관적 락을 사용한다.(예 : 좌석 예약)비관적 락 => 동시 요청시에 순차적으로 처리해야 하는 경우(예 : 재고 차감) 분산락 : 분산시스템에서 일관된
지난 5주간 무엇을 했나? 5주간 쉼 없이 달려왔다. 내가 맨 처음에 개발자로 공부할 때의 느낌처럼 지난 5주간 많은 양의 지식을 머리에 밀어 넣었다. 그리고 몰입해서 코딩을 하고 피드백을 받고 다시 수정하는 과정을 진행했다. 1주차에는 TDD 방식으로 포인트 충전, 사용을 할 수 있는 간단한 API를 구현했다. API 자체는 간단했지만 ConcurrentHashMap을 이용해서 동시성을 제어하는 부분이 있었다. 1주차를 통해서 TDD 방식을 익히고, 테스트코드 작성하는 방법에 대해서 연습이 많이 되었다. 그래서 이것을 기반으로 이후 과제부터 테스트코드 작성이 한결 수월해졌다. 2주차에는 클린아키텍쳐 + 레이어드 아키텍쳐를 공부하고 과제로 특강신청 API를 개발했다. 3주차 ~ 5주차는 본격적으로 서버구..
[테스트 코드는 왕이다] 내가 개발한게 잘 동작하는지 확인하기 위해서는 e2e, 통합테스트를 해야한다. 현재 한상진 코치님 사내에서 거대한 리팩토링을 진행중. 테스트코드가 완벽하게 구현되어 있고, 심지어 if문마다 테스트코드가 있다. 그래서 리팩토링하는 개발자가 리팩토링하면서 기능의 정확성이 보장되는지 판단할 수 있다. 테스트코드를 잘 작성하고, 꼼꼼하게 작성하는것은 매우 필요하다. 테스트코드 작성하는게 시간이 오래 걸린다? => 장기적으로 테스트코드를 작성하는게 시간을 절약해준다. 그렇지 않다면 PostMan으로 매번 수동으로 해야한다. [소프트웨어 아키텍쳐의 핵심은 책임과 의존이다] 책임 : 해당 프로그램의 기능 [서버구축 마무리 하면서] 맛집검색 서비스에 대한 리뷰 - API 1개에만 의존하다보면 ..
3주간의 콘서트 예약시스템 프로젝트가 눈 깜짝할 사이에 지나가버렸다. 퇴근하고 와서 코딩하고, 같은 조원들과 리뷰하고, 주말에 수업 듣고 복습하고 했던 과정들이 쉽지는 않았지만 개발에 몰입할 수 있는 기회여서 즐거웠다. 매번 멘토링 때 열정적으로 도움을 많이 주신 허재 코치님께 감사의 인사를 전합니다. 1. 프로젝트 소개 내가 개발한 프로젝트는 콘서트 예약시스템이다. 많은 사람들이 동시에 접속하여 콘서트 티켓 예매를 가정한 시스템을 개발하는 것이다. 콘서트 일정 조회, 토큰 발급, 좌석 예약, 결제 처리에 이르는 모든 기능을 종합적으로 구현해야 하는 프로젝트이다. 대용량 트래픽을 견뎌야 하는 시스템이기 때문에 동시성 제어 등 고민이 필요한 기능들이 있었다. 대용량 트래픽을 견디고, 동시성을 제어하는 시스..
1. 문제 (과제, 프로젝트를 진행하면서 부딪혔던 기술적인 문제) 1) 예약가능한 콘서트의 일자를 모두 조회하는 기능 위와 같이 Concert 테이블을 만들었다. Concert - Seat 테이블이 1:N 관계를 가지고 있는 ERD 설계를 했는데, 여기에 한계점이 있다. 각각의 concertDate마다 고유의 concertId가 있다. 그래서 concertId 1개로 여러개의 예약 가능한 콘서트 일자를 조회해 오는 것이 불가능. 중간에 ConcertOption 같은 테이블을 둬서 일자를 여러개를 동시에 조회해 올 수 있도록 Entity를 수정해야 함. 2) Jpa Repository로 조회시 Null과의 사투 JpaRepository로 객체를 조회해왔을 때 Null값이 많았다. 예를 들면 User use..
[문서를 작성하는 방법] 우리가 주니어 때 많은 글을 쓰지만 그것을 다시 보는 사람은 많지 않다. 다시 보는 글이 되려면 글이 컴팩트 해야 하고, 제목도 목적에 맞게 쓴다. 글을 툴처럼 만들어야 한다. [Loggin & Exception] 로그의 중요성 적절한 지점에 로그를 설정해놔야 운영상황에서 발생하는 에러나, 발생한 문제에 대해서 훌륭한 단서를 제공한다. 그럼 로그는 어느 지점에 달아야 하는가? 1. Request/Response를 받는 지점 입력값, 출력값이 최초에 어떤 값이 들어왔는지 알아야 하기 때문이다. Request 객체를 로깅하려면 Controller 부근에서 로깅처리 해야 입력값을 볼 수 있다. 그리고 Response의 경우도 Controller단에서 로깅처리를 해야 어떤 값으로 나갔는..
[1주차에 대한 회고] 테스트코드 짜는게 어렵다!! 1주차는 테스트 코드 짜는게 익숙하지 않아서 어려웠어요. 어떨 때 @SpringBootTest를 사용하고 어떨 때 @Mock을 사용하는지 몰랐습니다. 단위테스트와 통합테스트의 개념도 명확하지 않은 상태에서 테스트 코드를 작성했습니다. 테스트코드 작성방법에 대해서 찾아보고 해서 결국 테스트를 완성했습니다. 동시성 제어라는 것을 고민해보고 코드로 구현해볼 수 있는 기회가 있어서 유익하고 재미있었습니다. [2주차에 대한 회고] 사실 아키텍쳐에 대해서 생각을 안하고 늘 하던대로 패키지구조를 controller, service, repository를 만들어서 사용했어요. 그런데 아키텍쳐 구조에 따라서 각 프로그램 모듈의 성격이 달라지고, naming 방법도 달라..
[하헌우 코치님 과제 Summary] [E-커머스 과제] 1. 주문 결제할 때 Order Table, Order Item Table이 사실상 필수도. 2. ERD, 시퀀스 다이어그램 => 노션 머메이드 툴로 사용한다 3. 시스템 아키텍쳐 => 이레이져로 하면 멋있게 나온다. 4. PG연동 문서작성능력 > 코딩능력 [콘서트 예약 과제] 대기열은 어떤 부하를 낮추기 위해서 작업하나...? = DB 부하!(서버 부하X) 2. 좌석에 접근할 수 없도록 하는 경우 락을 사용하는데 실제 현업에서는 안정성을 위해서 비관적락을 사용하는 편이다. 낙관적락은 오류의 가능성이 존재. 3. 도메인은 무조건 테스트를 빡빡하게 할 수 있어야 한다. DDD는 추세다. 4. 다수의 인스턴스로 어플리케이션이 동작하더라도 기능에 문제가..
3주차에는
[질문] 1. 콘서트 예약시스템에서 대기열 시스템 구현시 RDBMS인지, REDIS 같은 것인지 구현하는 방식을 어떻게 의도하고 문제를 내신건지 궁금합니다 트래픽이 엄청 많지 않으면 DB 레벨에서 대기열을 구현이 가능하다. 그리고 DB에서 대기열을 구현하니 이게 한계가 있네, 그래서 REDIS를 사용하는구나에 대해서 꺠닫는데 의도. [질문2] [질문3] 폴링으로 대기열을 확인한다는 것은 배치작업 같은게 떠 있어야 하는걸까요? [질문4] 만약에 몇천명이 폴링으로 현재 대기자수를 DB로 갔다와서 알 수 있다면 부하가 심할 것 같은데요. 그러면 그 중간에 뭔가를 둬서 부하를 줄일 수 있어야할까요? private 메서드를 선언하는 케이스 - 허재코치님 : private 메서드는 잡다한 것을 프라이빗으로 선언. ..
안녕하세요 강정호입니다. 2주차 클린아키텍쳐를 끝내고 회고를 작성해봅니다. [잘하고 있는 점] 1. 어떻게 하면 효율적인 아키텍쳐로 설계를 가져갈까? 라는 고민을 하기 시작 2주차에는 허재 코치님이 레이어드 아키텍쳐, 클린 아키텍쳐에 대해서 설명해주셨어요. 2주차 특강신청 프로젝트에 해당 내용을 적용해서 아키텍쳐를 어떻게 짜면 가장 효율적일까? 라는 생각을 많이 하면서 과제를 진행했어요. 과거에는 아키텍쳐에 대한 생각없이 그냥 짰는데, 이제는 효율적인 방법의 아키텍쳐에 대해서 고민하며서 작성하게되었어요. 2. 다른 사람의 코드를 보고 내 것으로 차용하는 것 다른 사람들이 작성한 코드들을 보고 해석하여 내것으로 만드는 과정을 진행했습니다. 다른 조원, 6조 팀원들의 코드를 보고 의도를 생각하고 괜찮은 부분..
[허재 코치님이 깨달은 것] - "나는 지금까지 뭘 하고 있었던거지??" 라는 생각을 했다고 함. - 조금 더 체계적으로 개발을 하도록 미리 알았으면 좋지 않을까라는 생각을 했다고 함. - 체득을 하고 나서 개발하는 속도나 역량은 기하급수적으로 늘어났다. - 핵심 : 아키텍쳐, TDD 방식 등 체계적으로 개발하는 방법을 알면 더 코딩 실력을 높일 수 있다. [우리가 말하는 도메인이란 무슨 뜻이지????] 1. 도메인 : 특정 기능과 관련된 속성, 기능들을 "응집화" 시켜 놓은 개념. 예시1 : 도메인 이해도가 높아야 한다 ==> 해당 기능을 구성하는 응집화된 비즈니스 로직들에 대한 이해가 깊어야 한다. 예시2 : 도메인 모델 ==> 일반적으로 기능을 군집화 시킨 도메인의 객체, 엔티티 등을 의미 예시3 ..
1. 책의 개요 책 제목 신화는 없다 저자 및 출판사 이명박 지음. 출판사 : 김영사 읽은 날짜 2024. 01. 30. 총점 (10점 만점) 9점/10점 2. 책에서 본 것 제 3장 – 일을 장악하라. Key words: #타이금고사건 #불도저 해체 [내용 요약] - 타이 현장에서 금고를 지킨 이야기 인천의 폭력배들이 기능공으로 대거 뽑혔다. 타이 고속도로 건설현장에서 폭동이 일어났고, 이명박은 금고를 지키기 위해서 도망치지 않았다. 목에 칼이 들어오고, 구타를 당했지만 금고를 지켜냈고, 이후 이 소문은 한국 본사에 퍼져서 영웅담으로 유명해졌다. 과연 술에 취한 폭도들이 칼을 들고 올 때, 나는 금고를 지키기 위해 깡다구로 남아있을 수 있었을까? 하는 생각을 해본다. 한국에 가족도 있는데 내가 죽으면 ..
과제 : https://www.notion.so/teamsparta/2-782b11918d194acbba2416a758baf146 [요구사항 분석] 1. 특강 신청 API 구현 RQ-ID API 요구사항명 요구사항 내용 RQ-0001 특강신청 선착순 등록 사용자의 userId로 특강신청을 선착순으로 가능. RQ-0002 특강신청 중복신청 방지 * 특정 신청자가 신청내역에 있는지 확인 * 신청내역에 있다면 중복신청 불가 오류처리 RQ-0003 특강신청 특강 오픈 시간 * 특강은 24년 4월 20일 토요일 1시에 열린다. * 그 시간이 아닐 때는 신청 불가 메시지 출력 RQ-0004 특강신청 최대 신청자 제한 * 최대 30명까지 신청이 가능. * 신청내역에 30건이 되면 그 이후 신청에 대해서는 오류 출력 ..
[헥사고날 아키텍쳐] - 헥사고날 아키텍쳐는 도메인을 중심적으로 바라보는 것 - 모든 비즈니스 로직을 작은 단위로 만들어야 한다 - 쓰는 놈이 알아서 조립해서 완성할 수 있도록 [클린 아키텍쳐] - 가운데 과녁으로 갈 수록 관심사가 높아진다 - 도메인 엔티티가 [2주차 과제] 과제링크 : https://www.notion.so/teamsparta/2-782b11918d194acbba2416a758baf146 - User는 만들지 말고, UserID만 받아서 리퀘스트 하는 것 - 선착순으로 요청 - 의도 : 동시에 요청이 순서대로 보장되도록(선착순 30명 -> 이후 요청은 실패) - 핵심 : 테스트코드에 집중하기보다는 레이어드 아키텍쳐 기반으로 작성하고, 성장 가능한 서비스 구조를 만든다 그 구조를 잘 만..
[내가 해야할 것] 1. 단위테스트에 집중을 한다. 이게 TDD 방식. PointTable에 영향을 받는다. 그런데 단위테스트는 PointService 클래스의 메서드를 테스트하는 것에 집중해야 한다 그래서 주로 Mock Stub Spy를 사용한다. ==> 단위테스트를 하다가 빡세다? 라는 생각을 하면 결합도가 높은것이 아닐까? 라는 생각을 하게 된다. 그러다가 더 나은 구조에 대해서 고민한다. 이게 TDD의 목적 2. 동시성 제어할 때 현업에서 synchronize는 현업에서 사용하지 않는다 ConcurrentHashmap을 사용하는게 좋아보인다. 현업에서는 Redis를 사용해서 ConcurrentHashMap 기능을 사용한다. Queue 방식으로 워크플로우를 만들면 동시성 문제가 해결된다 3. 동시성..
Testable Code - 테스트 커버리지 100% 가 목표가 아니라, 각 요구사항에 대해서 정확히 기능을 하는지 테스트 하는 것을 목표로 한다. [너의 코드는] - 어떻게 하면 Testable 한 테스트 코드를 작성할 수 있을까? - 어떻게 테스트 가능한 코드를 작성할 수 있는지에 대한 발표이다. - 모델 : 해당 레이어(계층)에서 사용하는 데이터를 표현하는 객체 - 커플링을 줄이기 위해서는? - 이렇게 커플링을 줄이면 도메인을 엔티티로 전환시키는 비용이 든다. - 루즈한 커플링은 달성했지만 불필요한 작업이 생겼다. - 간결함을 갈 것인가 VS 결합도를 낮출것인가? - 케이스 1번 : 개발 불가 ㅋㅋㅋ 케이스 2번 : DDD 도메인을 JPA 모델이나 케이스 3번 : DB에서 나는 원하는대로 데이터를 ..
1. 지금까지의 회고 19년 7월부터 현재 회사에서 일해 왔고 이제 거의 근무기간이 5년이 가까워진다. 금융에 대해서 많이 배웠지만 기술적으로 성장에 목말랐다. 혼자서 인강도 들어보고, 스터디도 가입해서 개발을 했지만 지속적으로 하기 어려웠다. 현재 회사도 만족스럽지만 앞으로 더 큰 성장을 위해서는 한 번 더 도약을 할 필요가 있다고 본다. 2. 항해플러스 참여 계기 현재 금융권에서 사용하는 기술은 한정되어 있고 업무도 운영성 업무가 더 많다. 그래서 실제 현업에서 사용하는 기술을 바탕으로 실력을 높이고 싶다. 그리고 온전히 A to Z까지 내 힘으로 만드는 프로젝트를 경험하고자 한다. 이 경험으로 회사업무 외적으로 외주개발에 참여하거나, 내 서비스를 만들어서 배포하는 것이 목표이다. 3. 향후 5년 뒤..
- Total
- Today
- Yesterday
- 월급쟁이부자들
- Use case
- 깃허브
- docker
- 개발자 회고
- push_back
- 회고
- Inception
- ```````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````
- resize
- pop_back
- 깃
- 관계대수
- GIT
- Spring boot
- 2023년
- front
- 부동산공부
- github
- 유즈케이스
- 내년은 빡세게!!
- 바
- 도커
- 작성 방법
- 폭포수
- 월부닷컴
- 인셉션
- 재테크공부
- 열반스쿨기초반
- 파라메터
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |