본문 바로가기

TIL

 (53)
Bulk Insertion과 ORM 최적화 기존에 location과 place를 create_or_get할 때, 인스턴스 하나당 개별적으로 요청을 보내서 확인하는 작업을 진행했다. 시간이 되면 이를 개선하여 한 번의 요청으로 모든 데이터를 확인하고 생성하는 로직으로 변경하려고 생각하고 있었는데 place 와 location 관계를 다시 복구 하면서 같이 리팩토링하게 되었다. location은 비교적 간단히 처리할 수 있었지만, place 모델은 내부에 place_type 모델과의 관계가 있었기 때문에 생각보다 시간이 걸렸다. 솔직히 시간좀 잡아 먹었다. 그래서 처음에는 하다가 그냥 또 빠르게 바꿀까 해서 add_all을 생각했지만, 이건 사실상 기존에 하던 로직이랑 다를바가 없어서 스스로를 다독여 유혹에 빠지지 않고 작업을 계속 진행 했다. 처음..
결합과 추상화 파이썬으로 살펴보는 아키텍처 패턴을 보다가 3장 부분에 종종 생각하던 부분이 있어서 정리해 봤다. 테스트에 관련한 부분이다. 추상화에 대한 이야기를 하는데, 설계를 위한 추상화다. 그리고 테스트는 그 설계를 위함이 우선이라고 한다. 그래서 첫 번째는 그냥 돌아가게 구현하고 리팩터링 하는 식으로 이어지는데, 테스트를 위해 다른 방식으로 구현하는 예시도 보여준다. 3.3 선택한 추상화 구현 중요 로직을 명확하게 빼서 추상화하는데 여기 예시의 구현을 간단히 정리하면 외부 상태에 대해 아무 의존성이 없는 코드의 '핵' 을 만들고 외부 세계를 표현하는 입력에 대해 핵이 출력한 걸 처리한다. 그니까 중요 비즈니스 로직을 추상화해서 따로 빼놓는다. 이렇게 예시를 직접 보니까 추상화를 하면 테스트하기가 훨씬 쉬워지는 ..
API 요청 모듈 계층 분리 과정 Meet-up-spot이라는 만남 장소 추천 웹애플리케이션 프로젝트를 혼자 진행한다고 정신이 없었는데, 정신이 없어서 그랬는지 프로젝트하면서 섣부르게 진행한 부분에서 수정할 부분을 발견했다. 원래는 구글 maps api 요청을 직접 보내는 모듈을 작성해서 작업하고 있었는데, 보니까 애초에 라이브러리가 있더라. 아무리 그래도 너무 급하게 진행했던 거 같다. 근데 보면 라이브러리가 최근 api를 반영을 못해서 만약 사용한다고 해도 직접 요청 보내는 부분도 필요할거 같아 보였다. 사실 기능만 같으면 예전 것을 써도 되는데 테스트하는 과정에서 안 되는 게 있어서 일단 최근 api 테스트해보고 확정 지어야겠다. 그리고 이건 계속 사용하면서 불편했던 부분이기도 한데, 카카오 맵이 api가 더 간단해 보여서 바꿀까 ..
TDD 3부 기억에 남는 부분 패턴의 주요한 통찰이 하나 있으니, 우리가 언제나 완전히 다른 문제들을 해결하는 것 같지만 우리가 푸는 문제 대다수는 사용하는 도구에 의해 생기는 것이지 직면한 외부의 문제 때문에 생기는 것이 아니라는 점이다. ... 객체를 적용해서 계산을 조직화하는 것은, 내부 생성된 공통적이고 부차적 인문제들을 역시 공통적이고 예측 가능한 방법들로 해결하는 가장 좋은 예 중 하나가 된다. 디자인 패턴의 엄청난 성공은 객체 프로그래머들이 보는 공통성에 대한 증거다. 하지만 디자인 패턴이라는 책의 성공은 이런 패턴들을 표현하는 어떠한 다양성도 모두 억업하고 말았다. 30장. 267page 디자인 패턴 중 내가 알아챈, 그리고 다른 이들도 알아채길 바라는 것은, 반복적 행동을 규칙으로 환원함으로써 규칙을..
TDD 2부 스터디하면서 읽은 3번째 책인데, 시간이 안 나서 계속 정리를 못하다가 오랜만에 정리 좀 하려고 한다. 1부 내용이 쉽지가 않아서 3부 패턴들까지 다 보고 다시 돌아가서 보면 좋을 거 같다. 2부도 1부와 같이 TDD 예시를 보여준다. 여기서는 테스트를 위한 도구를 구현하면서 TDD를 보여준다. 다시 한 장씩 천천히 정리해봐야겠다. 먼저 2부의 시작인 18장에서는 테스트 케이스를 작성하기 위해 사용할 프레임워크를 테스트 하기 위한 테스트 케이스를 작성하는 도입 부분이다. 테스트 코드가 실행되었는지를 테스트하는 코드를 작성한다. 1부에서도 계속 나왔지만 일단 상수값을 넣어서 빠르게 초록 막대를 보기 위한 작업을 먼저 한다. 그리고 그 구조에 맞게 테스트 코드를 작성한다. 중간에 여러 리팩토링에 대한 이야기..
객체지향의 사실과 오해 3~4장 3장은 추상화와 타입에 대해 설명하고 객체와의 관계에 대해서 이야기한다. 4장은 앞서 이야기한 것들을 바탕으로 역할, 책임, 협력이 구체적으로 어떻게 이뤄지는지 그리고 우리가 객체지향 프로그램을 설계할 때 어떤 식으로 접근해야 하는지 좀 더 구체적으로 이야기해준다. 3장에서 먼저 복잡성을 다루기 위해 추상화가 이뤄지는 두 단계를 설명한다. 첫 번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것이다. 두 번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것이다. page 77 객체지향 패러다임은 객체라는 추상화를 통해 현실의 복잡성을 극복하고 위의 두 차원을 올바르게 이해하고 적용하는 것이라고 한다. 위에서 말한 첫 ..
객체지향의 사실과 오해 1장~2장 이 책은 혼자 읽은 책은 아니고 저번 주부터 정글에서 같이 공부했던 친구들 몇 명과 북 스터디에서 진행하기로 한 책이다. 객체지향적으로 코드를 짜는 방법론이나 이런 게 구체적으로 나와있는 책이 아니라 제목에 있는 것처럼 잘못된 오개념('프로그래머의 뇌'란 책에서 말한 그런 오개념)? 들 그리고 편견들에 대해 다시 잡으면서 올바르게 객체지향 관점으로 사고할 수 있게 도움을 줄 수 있는 책이 될 거 같다. 이번 주는 1장 ~ 2장 을 읽었는데 단순한 요약보다는 내가 읽으면서 흥미롭게 느끼거나 기억에 남았던 점들을 정리하려 한다. 우선 본격적으로 1장에 들어가기전에 저자는 보통 우리가 객체 지향하면 클래스부터 떠올리고 그거에 관련해서만 생각하고 이야기하는 점들을 경계한다. 2장 마지막을 읽게 되면 한번 더 이..
This Week. 2.14 ~ 2.18 회사에 출근하고 거의 테스트 코드 리팩터링을 했다. 기존에 fixture 들로 짜인 코드들을 FactoryBoy라는 파이썬 라이브러리를 사용해서 리팩터링 했는데, 이게 내가 너무 조급한 건지 모델이랑 코드가 복잡해서 그런지 생각보다 어려웠다. 팩토리 보이 자체가 어렵다기보다는 결국에 이게 지금 서비스의 모델을 기반으로 테스트 모델들을 만들어줘서 결국 모델이 복잡하니까 더 헷갈렸다. 또 너무 조급해서 그런지 코드만 쳐다보고 있어서 시간을 효율적으로 못쓴 거 같다. 팩토리 보이를 쓰면 중복되는 테스트 코드량도 줄고 또 테스트 코드 작성하면서 서비스 전반적으로 파악할 수 있는 거 같다. relatedfactory이니 post_generation이니 구체적인 개념은 사실 공식문서에 더 정확히 나와서 공식문서를 ..

티스토리툴바