SW개발/개발이야기

    사이드 프로젝트, 어플리케이션 출시 회고

    지난번 어플 출시 소개에 이어 오늘은 출시까지의 과정, 경험에 대한 리뷰입니다. 약 4개월간 회사일과 병행하면서 느꼈던 점들을 주로 적었습니다! 사이드 프로젝트 기획 & 시작 🚀 배달비가 나날이 비싸지는 와중에, 절약하기 위한 방법이 뭐가 있을까 하면서 생각났던 아이디어로 어플을 출시하는 것을 기획하게 되었습니다. 바로 근처의 사람들과 파티를 만들어 공동 주문을 통해 배달비를 1/N 하는 것입니다. 처음에는 친구와 2인으로 시작하였지만, 사정상 혼자하게 되었습니다. 어플 출시 목표 ✨ 처음에는 스토어에 출시하는 것 자체에만 목표를 두었습니다. 출시 프로세스를 경험해본 적이 없었기에 좋은 경험이 될 것 이라고 생각했습니다. 기술 스택은..? ⚒️ 사이드 프로젝트이기 때문에 많은 시간을 할애할 수는 없었습니..

    [SQLAlchemy]dict 타입의 값 변경을 감지하지 못하는 이슈, 트러블 슈팅

    안녕하세요, 오늘은 SQLAlchemy에서 지원하는 Mutation Tracking을 사용하던 중 겪었던 이슈에 대한 해결 과정을 공유하려고 합니다. 설명하기 앞서, Mutation Tracking이란 무엇인지 알아보겠습니다. https://docs.sqlalchemy.org/en/14/orm/extensions/mutable.html#module-sqlalchemy.ext.mutable Mutation Tracking — SQLAlchemy 1.4 Documentation Mutation Tracking Provide support for tracking of in-place changes to scalar values, which are propagated into ORM change events o..

    [Python]PEP 570을 보며.. (feat. 커뮤니티의 중요성 & 커뮤니케이션)

    안녕하세요, 이번 포스팅에서는 지난 Function Parameter, Argument를 공부하면서 읽게 된 문서와 느낀점을 써보려고 합니다. 지난 포스팅 https://leffept.tistory.com/418?category=927799 [Python]Function Parameter, Argument 에 대하여 파이썬은 매우 자유도가 높은 언어이다. 따라서 함수를 사용하면서 인자값에 대해 큰 신경을 쓰지 않아도 에러 없이 편하게 프로그래밍을 할 수 있다. 하지만 그러다가 non-default argument follows def leffept.tistory.com PEP (Python Enhancement Proposals)란? 파이썬에는 PEP 라는 "파이썬을 개선하기 위한 개선 제안서" 라는 것..

    배공파용 플레이스토어 출시 (feat. 배달비 공유 & 사이드 프로젝트)

    안녕하세요, 블로그 주인장입니다. 오랜만에 인사 드리네요! 다름이 아니라 그간 열심히 글을 올리지 못했었는데 이번에는 새로운 소식을 가지고 돌아왔습니다! 약, 4개월간 사이드 프로젝트로 진행하며 개발했던 어플리케이션이 드디어 구글 플레이스토어에 출시가 되었습니다. 회사일과 사이드 프로젝트를 병행 하다보니 힘든 점도 많았는데요, 굳은 의지를 가지고.. 출시까지 완료 하였습니다 😄 어플리케이션 소개 긴말 필요없이 어플리케이션부터 소개하도록 하겠습니다. 배공파용 - 배달비 공유 (구글 플레이스토어) 배공파용 - 배달비 공유 - Google Play 앱 주변의 파티에 참여하여 배달 음식을 같이 시켜요 play.google.com 요즘처럼 배달비가 비싼 시대에는, 커피 한잔, 치킨 한마리 먹으려고 배달비 3~7천..

    명확하고 간결한 주석에 대하여 (feat. 읽기 좋은 코드가 좋은 코드다)

    지난번 포스팅에 이어 주석에 관련된 책의 내용을 정리해보려고 합니다. 주석 역시 협업을 하다보면 필연적으로 작성하게 됩니다. 없는 것보다는 있는 것이 좋은 주석이지만 때로는 없는 것보다도 못한 존재가 되기도 합니다. 주석을 명확하고 간결하게 다는법을 알아봅시다. 지난 포스팅 https://leffept.tistory.com/412 좋은 변수명을 짓는 것에 대하여 (feat. 읽기 좋은 코드가 좋은 코드다) 개발자라면 늘 고민하게 되는 부분이 있습니다. 바로 "변수명, 함수명을 어떻게 지어야 할까?" 에 대한 이야기 입니다. 변수명을 짓는 것에 늘 고민이 많은 것은 사실이지만, 대부분은 습관에 의 leffept.tistory.com 명확하고 간결한 주석 달기 주석을 간결하게 하라 // 💥 불필요한 주석 /..

    좋은 변수명을 짓는 것에 대하여 (feat. 읽기 좋은 코드가 좋은 코드다)

    개발자라면 늘 고민하게 되는 부분이 있습니다. 바로 "변수명, 함수명을 어떻게 지어야 할까?" 에 대한 이야기 입니다. 변수명을 짓는 것에 늘 고민이 많은 것은 사실이지만, 대부분은 습관에 의해 자주 사용한 변수명만 사용하게 되는 것 같습니다. 혹은 너무 생각을 많이한 나머지 잘 사용되지 않거나 어색한 네이밍이 나오기도 합니다. 대체 어떻게 지어야 명확하고 모두가 이해하기 쉬울까..라는 생각을 하다가 알게된 책이 있어 읽으면서 좋았던 내용을 정리해보고자 합니다. http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788979149142 읽기 좋은 코드가 좋은 코드다 - 교보문고 더 나은 코드를 작성하는 간단하..

    [테스트]테스트 커버리지 0%에서 98%까지의 경험기 2

    테스트 코드는 실제로 가치가 있나요? 테스트 코드의 장점 테스트 코드를 작성하면서 실제로 느낀 장점들은 정말 무수히 많습니다. 그 중 대표적인 몇가지에 대해 이야기해보도록 하겠습니다. 클린 아키텍처 먼저, 테스트 코드를 작성하면 클린한 아키텍처를 지향하게 됩니다. 테스트 코드 작성과 함께 기능을 개발해나가다보니 문득 이런 생각이 들었습니다. "내가 지금 작성하는 코드는 의존도가 너무 높아 뭔가 테스트가 어려울 것 같은데 ?" 평소대로라면 저는 기존에 프로젝트 내에서 사용되고 있는 방법, 스타일을 그대로 사용하여 개발을 하였습니다. 또한, 이미 잘 작동하는 부분일 경우에는 더더욱 코드를 유심히 살펴볼 일이 없었습니다. 하지만 버그 픽스와 같이 소스를 수정하는 경우는 필연적이기 마련인데, 항상 문제가 되는 ..

    [테스트]테스트 커버리지 0%에서 98%까지의 경험기 1

    개발을 하며 수도 없이 들어왔던 테스트 코드의 중요성, 과연 어떻게 시작해야 할까? 라는 의문점과 함께 시작한 프로덕션 환경에서의 테스트 커버리지 0%에서 98%로 만들기까지의 경험을 공유해보려고 합니다. 테스트? 그거 어떻게 작성하는건데? 테스트 코드를 작성해보았던 경험이 없었기에 맨 처음에는 도저히 어떻게 작성 해야하는지에 대해 감이 잡히지 않았습니다. 여러 자료들을 보며 공부하면서 처음 만들었던 테스트케이스는 특정한 API의 엔드포인트에 테스트 client를 통해 요청을 보내고 정상적인 응답(status 200)이 오는지에 대해서 검증하는 것이었습니다. 코드의 모든 부분에 대해서 작성을 하지는 않았고 새롭게 추가 기능을 개발할 경우에 테스트를 함께 작성하고는 했습니다. 하지만, 단순히 응답만을 as..

    [Django]검색 퍼포먼스를 향상하기까지의 과정 2

    4. Full Text Search 적용 (GIN Index) 검색을 하면서 SearchVector를 활용하면 LIKE가 포함된 SQL에 굉장히 효과적이라는 글을 여럿 찾을 수 있었습니다. Django 공식 문서에서도 나와있는 만큼 Full Text Search를 적용해보기로 합니다. https://docs.djangoproject.com/en/3.2/ref/contrib/postgres/search/ Full text search | Django documentation | Django Django The web framework for perfectionists with deadlines. Overview Download Documentation News Community Code Issues Abo..

    [Django]검색 퍼포먼스를 향상하기까지의 과정

    어느 서비스든 마찬가지로 운영됨에 따라 누적으로 쌓이는 데이터들이 존재합니다. 저의 경우에는 메시지 테이블이 그러하였는데, 총 row가 약 50m을 넘었습니다. 따라서, 메시지의 검색 날짜기간을 길게 해둔다면 결과가 나오는데까지 15초 이상이 걸리기도 하였습니다. (첫 검색 이후에는 약 2초 내외로 걸렸습니다.) 실제로 검색 기능은 자주 이용되기 때문에 개선이 필요하다고 생각되어 Django에서 퍼포먼스를 향상시켜보기로 하였습니다. 1. 프로파일링이 먼저 테이블의 row수가 절대적으로 많기 때문에 당연히 검색은 느릴 것이라고 생각되었습니다. 하지만, 생각하는 것과는 다른 곳이 문제였던 일이 종종 있었기에 프로파일링을 앞서 진행하였습니다. Query Inspector, silk, cProfile, Debu..