Pycon KR 2019
파이콘 KR 2019에 가보면서 들었던 꽤 좋았던 세션들 목록 + 내용을 간단하게 정리하면서 그 내용을 블로그에도 옮겨놓는다. 회사분들께 공유할 목적으로 적어놓아서 많은 부분이 빠져있고, 엄청 축약되어 있는 것도 있다.
틀린 내용이 있을 수도 있고, 정확하게 정리하지 못한 내용이 있을 수도 있으니… 알아서 감안하고 봐주세요..
Code review tips for Pythonistas
SQUEEZE Inc에서 사용하는 방법을 파이콘 재팬
Style Guide, Formatter
의견 다툼을 줄이기 위해서 자동 포매팅 도구를 적용하라
How to write PR
PR Template을 제공하는 것이 좋다. 발표에서 나온 내용 중에 우리한테 필요할만 한 것들은 사항들은 아래 정도이다.
- Description
- checked list
- related PR, Issues
- screenshot of UI changes
- dependency updates
너무 큰 PR은 리뷰하기 너무 힘들다.
- Splitting PR into small PRs
- makes reviews easy and reponsibility is clear
- Checking diff size by “danger”
Sharing Working In Progress
Draft PR을 적극적으로 활용하면, 구현이 끝나기 전 조언을 받을 수도 있고, 필요한 정보들을 공유할 수 있다.
how to write review comments
일관성 있게 코멘트를 달자. 일정한 규칙으로 내 의견과 사실을 구분해주자.
Long Discussion
- face to face로 가자. 제일 명확한 방법이다.
- Issue로 옮겨라. PR에서의 Long Discussion은 좋지 않다.
Mob Code Review
code review를 해야하는 PR들이 쌓여만 가고 merge를 할 수 없을 때 mob programming하는 것처럼 mob code review를 하자. 시니어 프로그래머만이 코드 리뷰하는 사항을 피할 수 있고(시니어 프로그래머의 코드 리뷰 관점을 주니어도 같이 배우게 되면서), 그 시간을 한정해서 빠른 피드백을 주고 받을 수 있다. (하나의 PR을 보고 다 같이 앉음)
Playful Comments
텍스트만으로는 너무 딱딱해 보이고 서로간의 감정이 차단되는? 그런 상황을 말하는 것 같다.
그래서 이모지가 과해보일 수 있어도 “정확한” 의사표현을 위해 달아주자. 이는 감정을 서로 주고받는 것이 목적이 아닌 정확한 의사표현이 목적이다.
Real World Async IO
lablup 분이 나오셔서 발표한 내용이다.
Async IO
PEP 3156 – Asynchronous IO Support Rebooted: the “asyncio” Module
- 병렬화 X, 이벤트 루프 기반으로 코드를 돌릴 수 있도록 함
- coroutine function을 선언해서 사용을 함
- asyncio.run vs asycnio.create_task
- 비동기 코드로 진입 vs 흐름 분기
Cancellation
- await이 있어야 cancel이 가능
- CancelledError가 raising 될 것
- await은 모두 future아니면 task이다
- what is futurue in python
- future -> 즉시 취소 및 완료, task는 clean up 작업을 위해 추가로 비동기 작업을 더 해야 한다.
- asyncio.current_task().cancel() vs raise asyncio.CancelledError 의 차이점
- 전자는 쓰지 말자. 해당 태스크 외부에서 에러가 레이징이 안되어서 알 수가 없다.
- Cacnelled Error는 명시적으로 잡아서 raise를 다시 하자
- create task의 최상위 코루틴이라면 raise를 안해도 되겠지만, 그런거 잘 생각해서 처리하자
Issue 32528: Change base class for futures.CancelledError - Python tracker
- 이제 baseexception으로 들어간다.
- python base exception은 keyboardinterrupt, system exit, generator exit, cancellation exception
Clean Up
- cancel하고 나서는 무조건 await를 한번 걸어줘야 한다. -> clean up
- asyncio.wait_for 호출하면 clean up까지 기다려줌 (대신 TimeoutError가 raising됨)
- clean up에서 coroutine 호출이 가능한 점을 간과하지 말자
- library가 cacnellable하지 않을경우 죽음이다. asyncio.shield를 사용해보자. cancel안한 것처럼 해주는 것이다.
- aiojobs aiohttp
- websocket같은 경우는 cacnel은 어떻게 처리를 해야하나?
- aioredis는 unsubscribe가 안됨. 커넥션 풀이 소진됨. subscribe는 인스턴스마다 하나 뚫어서 공동 사용 로컬로 브로드캐스트 해주자
- partial같은게 type 보존이 안되어서 버그가 나는 경우도 있다.
Structured Concurrency
- fire and forget 패턴 -> go의 go랑 비슷하다고 생각하자
- happy eyeballs 지원할 수 있으면 정말 좋다.
- task group, supervisor -> 이 기능은 구현이 다 안되어서 3.8에 못나온다…
Advanced Python testing techniques
위의 라이브러리를 살펴보자
- Feature
- Scenario
- Given
- When
- Then
- Scenario
- DSL을 잘 활용하는 듯 함.
- 기본적으로 구조는 다른 테스트랑 크게 다른 것이라기 보다는 Feature랑 Scenario가 앞에 붙는 것이 더 그런 듯?
- 조금 더 비즈니스 적인 요구사항에 대해서 집중하는 듯함
-
Parameterized test는 일반적인 테스트랑 비슷비슷
- 이 부분에 대해서 더 알아보자 -> 어떻게 더 잘 활용할 수 있는지, 라이브러리는 뭐가 괜찮은지. -> 또 오버엔지니어링은 아닌지? -> 근데 지금 글을 쓸때까지 또 안했네?? -> 나중에 다시 이 글을 보면서 bdd를 해볼 날이 오지 않을까?
단점 & 팁
- 자연어와 파이썬 코드의 분리 -> 디버그가 쉬울까?
- 최대한 atomic하게 문장을 구성하자
- given에서 context를 만들어서 when에서 수행한 동작을 context에 저장하고 then에서 확인하자
-
- 외부 서버 분리? -> HTTP Mocking
- github gabrielfalcao/HTTPretty
- 그럼 실패한 상황에 대한 처리 & timeout같은 네트워크 에러도 잘 할 수 있나?
-
- Monkey Patching
- module의 일부분만 mocking -> 파이썬같은 노근본 언어만 가능한 것은 아닌가? Java는 프록시 써여할 것 같은데
-
- Hypothesis
- test function을 random한 input을 받도록 만들어줌
- HypothesisWorks/hypothesis
- (그럼 이걸 사용한다면 한번도 실패하면 안되는 듯 하다)
-
- Benchmark testing
- ionelmc/pytest-benchmark
- 그래도 벤치마크는 오래 걸리는 테스트를 돌리기 위함이 아니라 짧게 걸리는데 최적화를 해야하는 테스트를 돌리는 것이 아닌가? -> 그냥 오래 걸리면 노이즈 제거가 안될듯…
-
- pytest plugin 필요하다면 작성해서 쓰자