항상 충실하게

무엇을 배웠는가?

2. 새롭게 시작한 일.

저녁 공부,

일의철학 읽고 적용하기

3. 누구를 도왔는가?

희열랜드 사람.

4. 무엇을 발견했는가?

나는 먼가 조금씩 풀려나가는것을 좋아한다.

0. 서

 과제를 하면서 이러한 생각을 차분하게 했다면 좋았겠지만, 시간에 쫓기고 팀원들과 함께하느라 못했으므로,, 리팩토링하면서도 해야겠다는 생각에 정리한다.

1.  문제의 해석

1) 왜 이러한 문제를 줬을까?

8 퍼센트는 핀테크 기업이다. 핀테크 기업에게 제일 중요한 것은 신뢰다. 사고는 곧바로 고객의 손실로 이어지거나 적어도 고객의 신뢰 저하로 이어진다. 때문에 견고하고 사고없는 프로그래밍이 매우 중요하다. 이에 따라서 계좌의 잔액과 거래내역의 잔액 무결성이라던지, 1억건이 넘어가더라도 손실이 없고, 빠르게 찾을 수 있는 부분에 대한 고려가 필요하다.

극단적으로 보수적으로 잡도록 할것이다.

2. 문제의 해결

1) 잔액 무결성

트랜잭션의 무결성을 유지하도록 설계가 되어야한다.

이러기 위해서는 원자성, 일관성, 고립성, 지속성이 유지가 되어야한다.

(1) 원자성이 보장되기 위해, atomic을 수행한다.

기본적으로 장고는 auto_commit이다.

이에 따라 해당 계좌에 가서,  잔액을 바꾸고 거래내역을 등록하는 이 2가지 행위가 한번에 이루어져야하지만, 각각 이루어질 우려가 있으므로, **with transaction.atomic()**을 넣어줘야 한다.

(2) 일관성 같은 경우는 테이블이 생성될 때 명시되므로, 크게 신경 쓸 필요없다.

(3) 고립성을 보장하기 위해, 동시성 제어를 한다.(concurrency control)

• 은행이니 만큼, 최고수준의 격리를 하여서 안정성을 확보해야한다.
• 쓰기와 관련된 충돌은 select_for_update()를 통해서 방지한다.
• 읽기/읽기와 관련된 충돌은 고립수준을 serializable 모드로 하여서 방지한다.
• *TMI:

main -replica db로 나뉘어져 있는 상황에도 isolation을 신경써야할까?

• 그렇다. 왜냐하면 main db가 다운되면 replica가 maindb가되기 때문이다.

(4) 지속성 역시 aws에서 로그기록을 남기도록 설정하였다.

추가적으로 aws-rds에서 multi-az를 활성화하였다.

이를 통해 혹시나 생길 db instance 중단에 standby replica로 대체하도록 하였다.

2) 1억건의 데이터고려

1. 인덱싱
   • main db 와 replication db로 나누어서, write, update는 main에서만 하고, read는 replication db 에서만 가능하게 한다.
2. 거래방식(입금인지,출금인지)과 계좌번호로 인덱싱하였음.
3. 월별 partinioning:
   1. partition의 기준을 월로 한 이유비즈니스 로직에 따라, 연이나 주단위로 하는 것보다 월단위로 하는 것이 효율적이라 판단하였음.
   2. 카카오뱅크나 기타 다른 은행앱들을 보면, 1개월, 3개월 단위로 거래내역 목록을 볼 수 있게 해놓음.

리팩토링 중입니다..

https://semper-fide1is.tistory.com/115

1. fast api 도전기

2. sql 공부하도록하자

3. 하나의 문제점에 대한 다양한 생각

4. 팀 협업에 있어서의 문제점들.

월~수: 원티드 프리온보딩 참여함

그간에 배운점들

1. 생각보다 소통이 어려움

특히 페어프로그래밍 할때 느꼈는데,

내가 지칭하는 것과 페어분이 받아들이는게 다를때 가 있다는점.

--> 앞으로는 좀 더 명확하게 전제조건을 깔고, 맥락이 담긴 언어를 구사해야겠음

2. nosql류 처음 써봄

언제나 그렇듯 처음해보니 어렵더라.

unique_key를 안줘도 되는점이나, 그냥 foreign key를 주면되는 것들이 다른 식으로 구현가능하다는 점.

배운점 잘 정리해봐야 겠다.

-->https://semper-fide1is.tistory.com/70 정리중

3. CI/CD의 중요성

ci/cd를 해야 제출시간까지 안전하게 배포할 수 있겠더라

--> 도커 다시 복습

오늘의 깨달음.

앎의 시작은 무지를 자각하는데 있다.

- 개발자 오디세이아

일단 모르는 것을 다 적어보자.

1. 객관

자바 스프링 학습

fixture에 대한 고민

2. 주관

테스트 몇번 써보니 약간은 알거같은 느낌

3. 배운점

"이메일이 저장되어 있지 않은 경우"와 "이메일을 찾지 못한 경우"는 다릅니다. 컴퓨터를 다룰 때에는 무엇이 "없다"라고 단언하면 곤란할 수 있습니다. 이게 조회를 하는 순간에 DB에 무슨 일이 생겨서 조회가 실패한 건지, 정말로 데이터가 존재하지 않아서 실패한 건지, 아니면 그냥 내 컴퓨터가 인터넷이 끊어져서 실패한 건지 아주 짧은 시간 동안에 확실히 알아내기란 매우 어렵습니다.

이건 오라클하고는 아무런 관련이 없어요. 개발자들끼리 합의한 것도 아닙니다. 이건 객체지향 원칙이 주석에도 적용된 것 뿐이에요. 그리고 그것이 적용된 이유는 javadoc이 메소드의 바깥이기 때문입니다. javadoc은 실제로 외부에 보여주기 위한 문서이기도 하고요, 메소드를 사용하고 있는 다른 클래스에서 메소드까지 점프해 오지 않고도 javadoc을 IDE에서 볼 수 있기 때문이기도 해요.

4. 확언

내일 요구조건 다 맞춘다. 뽀모도로를 한다.

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=phrack&logNo=80131666250 

https://jaehun2841.github.io/2019/02/24/effective-java-item56/#%EB%AC%B8%EC%84%9C%ED%99%94-%ED%83%9C%EA%B7%B8

1. 객관

dp 문제들을 품. 감을 익혀가는지도?

스프링 과제를 함.

doc쓰는 법을 익힘

아침에 못일어났지만 결국 운동을 하러 갓다.

2. 주관

스프링은 해도해도 안느는 느낌 2222

https://youtu.be/4ppfESa0EtE

3. 배운점

1) 스마트한 시간관리, 인생관리 습관 6장

 특정한 모임이나 시간 약속이 얼마만큼의 가치를 갖는지 따져볼것.

깊이 활동해야한다는 것을 잊지말것.

한번에 하나씩 할것.

2)

개발자는 결국 문제해결 능력이다.

4.  확언

나는 내일, 알고리즘 문제를 복습하고, 스프링에 딥다이브할 것이다.

그러기 위해서 뽀모도로를 도입할 것이다.

1. 객관

코드숨 강의를 들음

김영한 강의 +백기선 강의 약간 들음

스마트한 시간관리, 인생관리 습관 책 읽음

dp 두문제 품

데이터베이스 책 약간 읽음

2. 주관

스프링은 해도해도 안느는 느낌?

3. 배운점

1) 스마트한 시간관리, 인생관리 습관 5장

충분하고, 지속적이고, 집중적인 관심은 성공의 열쇠이다.

이러한 관심 쏟는 것을 방해하는 저항 미루기등을 이겨내야한다.

책에서는 미룰시에 이에 대한 처벌을 해결책으로 내세우는데,, 음,,, 저항을 방지하는게 낫지 않을까? 싶다.

사실 코딩도, 스프링도 결국 comfort zone을 벗어나려는 노력에서 실력이 느는 것 같다.

2) 스프링에서 jwt를 다루는 방식

3)

궁금한것: why dto?

없으면 어떻게 되지?

필수적인 것인가?

mockMvc에 대하여

4)

Mock: 진짜 객체와 비슷하게 동작하지만 프로그래머가 직접 그 객체의 행동을 관리하는 객체.

Mockito: Mock 객체를 쉽게 만들고 관리하고 검증할 수 있는 방법을 제공한다.

애플리케이션이 데이터베이스 혹은 api 호출한다고 가정하면,

외부 api가 어떻게 동작하는지,

예측해서  관리해야함.

https://martinfowler.com/bliki/UnitTest.html

단위라는 개념: 

하나의 행동이라고 보기도함.

그냥 정하면 되는 것.

@ExtendWith(MockitoExtension.class)

class StudyServiceTest {



    @Mock MemberService memberService;



    @Mock StudyRepository studyRepository;

@ExtendWith(MockitoExtension.class)

class StudyServiceTest {

    

    @Test

    void createStudyService(@Mock MemberService memberService,

                            @Mock StudyRepository studyRepository) {

        StudyService studyService = new StudyService(memberService, studyRepository);

        assertNotNull(studyService);

    }



}

https://velog.io/@ausg/Mockito-Test-Framework-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

4. 확언

내일은 comfortzone을 벗어나느 코딩을 할 것이다.