항상 충실하게

45살때부터였다.

- 논리적이고 싶은가? --> 글을 써라

- 감정을 어떻게 다스리는가? --> 글을 써라

- 그냥 써라, 어차피 관심없다.

- 꾸준히 그냥 써라.

--> 나도 꾸준히 써보자.

마음을 얻는 심리활용의 비밀

- 마음을 활용하는 여러가지 사례들이 나옴.

1. 감정적 지불을 할 것

- 흔히 말하는 공감.

- 상대방의 가치 인정해주기

- 상대방의 두려움을 해소해준다.

- 인식을 돌리기 위해서도 필요하다.

2. 공공의 적 찾기

3. 숨은 무형의 가치 찾기.

4. 어조와 태도 중요

5. 자료를 제시하는 방법도 중요.

6. 제3자의 중재

사실 인간은 감정의 동물인데, 감정에 관한 능력을 키우지 않으려하는것은 오만에 가까운듯.

지능의 이슈일수도.

(감정적, 사회적 지능)

결국 가격 협상을 하려면 상대방의 표준을 이용하고, 유대적 관계를 쌓아야한다는 이야기.

자칫 잘못하면 얘가 이득을 얻어내려고 나랑 친분을 쌓으려고하나?라는 의심을 사지 않을까?

--> 이걸 잘 풀어내는게 협상 능력일듯.

그래도 인간적 소통이 중요하다는 인사이트.

회사에서 인정받는 사람들의 비밀

- 상대의 머릿속을 그리는 일이 중요하다.
- 회사 내에서 협상의 목표는 보다 가치있는 존재가 되는 것.
- 내 가치가 높아질수록 더 높은자리로 올라갈 수 있고, 해고의 위험이 줄어들기 때문.
- 이력서를 넣을때도 상대방의 머릿속을 그리고 점진적으로 다가갈것.
- 목표달성을 위한 정보를 수집할것.
- 표준을 활용할것. 표준뒤에 있는 핵심을 파악할 것.
- 상상력을 발휘해서 그들 뒤에 있는 욕구를 파악하고 충족시킬 것
- 제 3자를 활용할 것,

무엇을 배웠는가?

2. 새롭게 시작한 일.

저녁 공부,

일의철학 읽고 적용하기

3. 누구를 도왔는가?

희열랜드 사람.

4. 무엇을 발견했는가?

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

1.1 읽기 쉬운 코들르 만드는 것이 왜 중요한가?

• 코드는 한번 작성되면 여러번 읽힘.
• 나중에 읽는 사람이 훨씬 편해지고, 관리가 쉬워짐
• 이를 위해서 지켜져야하는 원칙들
  • 축약적이거나 함축적인 변수명은 피한다
  • 함수 인자의 이름들은 꼭 써준다
  • 클래스와 메서드를 문서화한다
  • 코드에 주석을 꼭 달도록 한다
  • 재사용 가능한 함수 또는 메서드 안에서 반복되는 코드들은 리팩터링을 해둔다
  • 함수와 메서드는 가능한 한 작은 크기를 유지한다. 어림잡아 스크롤 없이 읽을 수 있는 길이가 적합하다

적용해볼점:

1) 그냥 변수명 길게 쓰자.

2) 문서화 꼭 하자.

3)주석,,,?흠... 추후에 더 살펴보도록하자.

4) 리팩토링 노력해보자

1.2 pep8

flake8을 이용하도록하자.

1.3 import들

pep8에 따르면

1) 표준라이브러리

2) 연관외부 라이브러리

3) 로컬 애플리케이션 또는 라이브러리에 한정된 임포트

이 책에 따르면

1) 표준라이브러리

2)코어 장고 임포트

3)서드파티

4)프로젝트앱임포트

1.4 명시적 성격의 상대 임포트 사용하기 (explicit relative import)

• 명시적 상대 임포트:
  • from .models import WaffleCone
• 앱의 이름을 변경할 일이 생기거나, 이름이 충돌되는 경우를 피할수 있다.
• 재사용하는 경우 바로 사용할 수 있게됨.
• anti-pattern
  • from cones.models ~~
  • from models import ~~ (implicit relative import 이것도 안티패턴임.)

1.5 import *은 피하자

이유: 다른 python module의 namespace들이 우리가 작업하는 module의  namespace에 추가로딩되거나, 기존것에 덮여쓰이는일이 발생할 수있다.

1.6 장고 코딩 스타일

https://docs.djangoproject.com/en/4.0/internals/contributing/writing-code/coding-style/

이것을 따르도록하자.

1.6.2 

(이 파트는 Two scoops of Django 3.x 영어판을 참고함)

실제 매핑되는 url은 대시를 써도된다.( Dashes in actual URLs are fine (e.g. route=’add-topping/’ )  

#안티패턴
  patterns = [
       path(route='add/',
           view=views.add_topping,
           name='add-topping'),
       ]
       
#good pattern
patterns = [
       path(route='add/',
           view=views.add_topping,
           name='toppings:add_topping'),
       ]

더보기

(이 글 작성자 주.

장고 초심자를 위해서 (나다. ) name은 도대체 언제 쓰이는지 알아봤다.)

https://docs.djangoproject.com/en/4.0/topics/http/urls/#:~:text=Reverse%20resolution%20of%20URLs%C2%B6

 

URL dispatcher | Django documentation | Django

Django The web framework for perfectionists with deadlines. Overview Download Documentation News Community Code Issues About ♥ Donate

docs.djangoproject.com

from django.urls import path

from . import views

urlpatterns = [
    #...
    path('articles/<int:year>/', views.year_archive, name='news-year-archive'),
    #...
]



##########################
<a href="{% url 'news-year-archive' 2012 %}">2012 Archive</a>
{# Or with the year in a template context variable: #}
<ul>
{% for yearvar in year_list %}
<li><a href="{% url 'news-year-archive' yearvar %}">{{ yearvar }} Archive</a></li>
{% endfor %}
</ul>

#########################
from django.http import HttpResponseRedirect
from django.urls import reverse

def redirect_to_year(request):
    # ...
    year = 2006
    # ...
    return HttpResponseRedirect(reverse('news-year-archive', args=(year,)))

+

그 name에 언더스코어를 써야하는 이유가 이게 더 pythonic하고, IDE랑 text editor에 친화적이라서.라고 되어있어서 실험을해봤다.

직접 해보니 대시를 마이너스로 인식하는 경우가 있더라.

1.8 통합개발환경이나 텍스트 편집기에 종속되는 스타일의 코딩은 지양한다.

(다른 에디터를 쓰는 사람들도 있기 때문.)

리팩토링 전 상태: https://github.com/Wanted-preonboarding-team4/8percent-assignment-2

리팩토링 repo : https://github.com/Heon4856/8percent-assignment-2

리팩토링 전 상태 점검

1. serializer가 없어서, view 단의 코드가 지저분함 

2. 테스트 코드가 미비함.

3. 거래내역 1억건에 대한 고려나, 잔액 무결성에 대한 고려가 빈약함.

이에 따른 리팩토링 계획

0. 과제의 의도 파악하기.

1. drf 도입을 통해 view 단 코드 정리 --> 했음.

2. 테스트 코드 작성 -->12.11 하는 중

3. 거래내역 1억건에 대한 풍부한 고려 및 잔액 무결성에 대한 고려를 할 것.  -->했음.

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