항상 충실하게

무엇을 배웠는가?

2. 새롭게 시작한 일.

저녁 공부,

일의철학 읽고 적용하기

3. 누구를 도왔는가?

희열랜드 사람.

4. 무엇을 발견했는가?

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

나쁜 코드란?

1. 성능이 떨어지는 코드

2. 의미가 모호한 코드

3. 중복된 코드

나쁜 코드를 쓰면 안되는 이유

1. 깨진 유리창의 법칙

2. 생산성 저하 --> 팀생산성까지, 기술부채

3. 수정하려해도 새로운 시스템도입 필요

나쁜 코드를 생산하는 이유

1. 일정 촉박해서

2. 고쳤다가 다른 곳에 영향을 미칠까봐

그렇다면 좋은 코드란?

1. 성능이 좋고

2. 의미가 면확하고

3. 중복이 없는 코드

한가지를 제대로하는 코드를 쓸것.
잘 쓴 문장처럼 읽히게 할 것.

보이스카웃룰 지키기.

스니펫: 특수한 목적을 위한 코드

디자인: 문제에 대한 해결책

스탠다드: 문제를 해결하는 대표적인 방식 포괄적임

패턴: 유효성이 검증된 효율적이고 확장 가능한 해결책

참가자: 디자인 패턴에서 사용되는 클래스

비기능적 조건: 메모리 최적화와 사용성, 성능등이 여기에 속함. 솔루션 전체에 영향을 미치는 핵심적인 요소

생성패턴

- 객체가 생성되는 방식을 중시

- 객체 생성관련 상세 로직을 숨긴다

- 코드는 생성하려는 개체형과 독립적

구조 패턴

- 클래스와 객체를 더 큰 결과물로 합칠 수 있는 구조로 설계

- 구조를 간결화하고 클래스와 객체간의 상호관계 파악

- 클래스 상속과 컴포지션을 중시

행위패턴

- 객체간의상호작용과 책임을 중시

- 객체는 상호작용하지만 느슨하게 결합돼야한다.

- 파이선 디자인 패턴 출처.

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 통합개발환경이나 텍스트 편집기에 종속되는 스타일의 코딩은 지양한다.

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

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

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

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

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

이에 따라 해당 계좌에 가서,  잔액을 바꾸고, 거래내역을 등록하는 이 2가지 행위가 각각 이루어질 우려가 있으므로,

with transaction.atomic()을 넣어줘야 한다.

참고:

https://brownbears.tistory.com/573

https://docs.djangoproject.com/en/4.0/topics/db/transactions/

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

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

-은행이니 만큼, 최고수준의 격리를 하여서 안정성을 확보해야한다.

-main db 와 replication db로 나누어서, write, update는 main에서만 하고, read는 replication db 에서만 가능하게 한다.

-쓰기와 관련된 충돌은 select_for_update()를 통해서 방지한다.

-읽기/읽기와 관련된 충돌은 고립수준을 serializable 모드로 하여서 방지한다.

**TMI:

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

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

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

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

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

https://support.bespinglobal.com/support/solutions/articles/16000038897--aws-rds-multi-az-

리팩토링 전 상태: 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억건에 대한 풍부한 고려 및 잔액 무결성에 대한 고려를 할 것.  -->했음.

1. 파이썬 버전은 3.8, 3.9, 3.10 만 지원함

2. tmizeon은 zoneinfo가 default임

3. UniqueConstraint가 생김.

흠....그 외에는 아직 장고 초심자여서.. 바뀐것이 어떤의미인지 잘모르겠음.

https://www.youtube.com/watch?v=bE23wioMGao 

https://docs.djangoproject.com/en/4.0/releases/4.0

from collections import deque

n, m = map(int,input().split())
temp = []
for _ in range(n):
    aaa = input()
    aa = []
    for a in aaa:
        aa.append( int(a))

    temp.append(aa)

# print(temp)
dx = [0, 0, -1, 1]
dy = [-1, 1, 0, 0]


visited=[(0,0)]
round = 0
stack = deque ()
stack.append((0,0, 0) )
pointX = 0
pointY = 0
while pointX != n-1 or pointY != m-1:
    pointX, pointY, round =stack.popleft()
    for i in range(4):
        temp_pointX  =pointX+ dx[i]
        if temp_pointX <0 or temp_pointX> n-1:
            continue
        temp_pointY  =pointY+ dy[i]
        if temp_pointY <0 or temp_pointY >m-1:
            continue
        if temp[temp_pointX][temp_pointY] ==0:
            continue
        else:
            temp[temp_pointX][temp_pointY] = 0
            stack.append((temp_pointX, temp_pointY, round+1) )


print(round+1)